Интересно..

А толку?

Блин, дожились. Ну сколько можно велосипеды изобретать?! Уже есть apt-get и ему подобные, нафига еще выкаблучиваться? Пакуйте в .deb или в .rpm, пишите ебилды в конце концов... Нет, надо изобрести что-то свое, и гордо назвать это олицетворением мечты всех юзеров планеты Земля... Сколько можно уже?

Java WebStart? :-)

> Блин, дожились. Ну сколько можно велосипеды изобретать?! Уже есть apt-get и ему подобные, нафига еще выкаблучиваться? Пакуйте в .deb или в .rpm, пишите ебилды в конце концов... Нет, надо изобрести что-то свое, и гордо назвать это олицетворением мечты всех юзеров планеты Земля... Сколько можно уже?

а если не хочется в систему ставить? вот мне этот самый firefox-1.6a1 вкорячивать в систему -- никакого желания. а на посмотреть -- интересно. и что делать?

> Java WebStart? :-)

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

> а если не хочется в систему ставить? вот мне этот самый firefox-1.6a1 вкорячивать в систему -- никакого желания. а на посмотреть -- интересно. и что делать?

Знаешь, в юниксе нет реестра, и прочей бинарной фигни, поэтому понятие "вкорячивать в систему" тут немного не действует. В крайнем случае, можно поставить в /usr/local или /home/user. Работоспособность программы от этого не изменится (если она нормально написана, конечно).

> Знаешь, в юниксе нет реестра, и прочей бинарной фигни, поэтому понятие "вкорячивать в систему" тут немного не действует. В крайнем случае, можно поставить в /usr/local или /home/user. Работоспособность программы от этого не изменится (если она нормально написана, конечно).

применительно к файрфоксу это означает:

1. качать и компилить (руками, ибо emerge super-latest-firefox затрет системный 1.0.6)

2. качать бинари с мозиллы.орг и надеяться что они заведуться с произвольного места (ибо в файрфоксе реестр _есть_)

3. или скачать один .cmg, про который известно что он работает.

> 1. качать и компилить (руками, ибо emerge super-latest-firefox затрет системный 1.0.6)

Из инвалидности emerge не следует то, что необходимо изобретать новый формат пакетов.

> 2. качать бинари с мозиллы.орг и надеяться что они заведуться с произвольного места (ибо в файрфоксе реестр _есть_)

Сделай бекап ~/.mozilla.

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

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

Поставь несколько программ в /usr/local/, а потом попробуй некотрые удалить.

Основная идея -- максимальная простота ознакомления (тестирования, перевода) новых development-версий программ.

Автор статьи предполагает использование текущей системы обновления/упаковки пользователями для стабильных версий программ.

Это не аналог dmg, т.к. dmg используется для передачи mac-программ по сети (чтоб ресурсы не потерялись). Установка там заключается в копировании программы (на самом деле специального каталога) из dmg в любое место на жёстком диске (чаще всего в папке Applications). Здесь же такого копирования не происходит. Просто эти системы используются для разных вещей.

> ибо в файрфоксе реестр _есть_

Вот с этим и надо бороться! Приводить конфиг файрфокса в читаемый вид, документировать его. А не бороться с симптомами болезни, изобретая костыли.

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

тебе шашечки или ехать? и вообще -- где ты видел неинвалидные проги в принципе?

впрочем, суть этой вещи не в том что бы пускать firefox. лично мне было бы здорово пойти на kde-apps.org и видеть ссылки вида klik://try_very_new_and_not_yet_widely_known_app_now

Это не только для мозилы.
Идея такова: _разработчик_ собирает исходный klik пакет, выкладывает на сервер, там он собирается под различные ОС. _Разработчик_ информирует своих тестеров, usability экспертов и другой народ что можно попробовать новую версию программы.

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

> Это не аналог dmg, т.к. dmg используется для передачи mac-программ по сети (чтоб ресурсы не потерялись). Установка там заключается в копировании программы (на самом деле специального каталога) из dmg в любое место на жёстком диске (чаще всего в папке Applications). Здесь же такого копирования не происходит. Просто эти системы используются для разных вещей.

ну не совсем. для паковки атрибутов спокон веков stuffit пользовался. dmg -- это наиболее близкий аналог cmg поскольку и там и там (насколько мне известно) происходит монтирование образа. и ровно так же как можно прожки из dmg пускать без установки, так и из cmg можно инталлятор пускать если кому хочется (хотя странная идея, конечно).

> Далеко не все дистрибьютивы собирают development-версии

Так не пользуйтесь такими нехорошими дистрибутивами. Кроме того, что мешает разработчику собирать вместо "klik пакета", deb-пакет?

> Идея такова: _разработчик_ собирает исходный klik пакет, выкладывает на сервер, там он собирается под различные ОС.

интересно, а каким образом будут учтены различия между ОС? И что мешает разработчику, например, собрать все в .deb пакет? Не понимаю, в чем заключается "невелосипедность" поделки?

> Поставь несколько программ в /usr/local/, а потом попробуй некотрые удалить.

Ежу понятно, что не ручками ставить надо. ТОгда таких проблем не будет. Я не отрицаю, что идея хорошая. Я утверждаю, что это не мечта, как сказано в статейке, а уже давно суровая реальность жизни.

Хочется добавить, что как часто случается на ЛОР, новость содержит какие-то вершки (как это устроено), но не описывает главного (зачем это нужно (инструмент для увеличения круга разработчиков непрограммистов (тестеров, переводчиков, художников и т.д.)), альтернативой чего это является(NX server)).

Ещё раз -- это не замена основного способа пакетирования в дистрибьютиве, хотя, при желании, может стать дополнительным (особенно удобно для LiveCD).

> интересно, а каким образом будут учтены различия между ОС? И что мешает разработчику, например, собрать все в .deb пакет? Не понимаю, в чем заключается "невелосипедность" поделки?

а что, ты предлагаешь мне на генту ставить deb-ы?

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

более того, совершенно уверен что "установить deb присланный по мылу" это не то же самое что "запустить прожку".

> Хочется добавить, что как часто случается на ЛОР, новость содержит какие-то вершки (как это устроено), но не описывает главного (зачем это нужно (инструмент для увеличения круга разработчиков непрограммистов (тестеров, переводчиков, художников и т.д.)), альтернативой чего это является(NX server)).

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

> а что, ты предлагаешь мне на генту ставить deb-ы?

Я тебе ничего не предлагаt. Я спросил, каким образом будут учитываться различия между ОС. А ты начала отвечать вопросом на вопрос. Это нехорошо.

> А ты начала

Блин, опечатка. :) Прошу прощения. Устал просто сегодня.

dmg заменил stuffit из-за того, что это не Apple-программа, сняли лишнюю зависимость на внешнюю программу.

Кроме того, при двойном щелчке на архиве архив распаковывается и удаляется. При двойном щелчке на dmg он только монтируется. Т.е. так удобнее хранить дистрибьютивы.

dmg--для хранения дистрибьютивов, cmg -- для запуска программ. cmg ближе к папке с mac-программой, но это уже всё-таки тонкости.

> Я тебе ничего не предлагаю. Я спросил, каким образом будут учитываться различия между ОС. А ты начал отвечать вопросом на вопрос. Это нехорошо.

:-) отвечаю -- никак. то как оно сделано сейчас предполагает что в системе есть некий набор системных либ (от glibc до libxml2 и kdelibs). все что кроме этого -- должно паковаться с прожкой.

предполагает ли это стабильный ABI в пределах архитектуры на который может полагаться девелопер? да, предполагает. хорошо ли это? _очень_ _хорошо_!

к примеру, ситуация с тем же kde в этом плане очень хороша. kde-шние библиотеки совместимы бинарно по всей линейке 3.x.x. с гномом все кажется сложнее, но что тут было сказано за кривые поделки? :-)

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

> dmg--для хранения дистрибьютивов, cmg -- для запуска программ. cmg ближе к папке с mac-программой, но это уже всё-таки тонкости.

:-) убедил. впрочем, название "cmg" явно неслучайно.

кстати, рекомендую почитать про смысл и философию этой задумки:

http://klik.atekon.de/docs/?page=Philosophical%20articles

то, в каком виде klik есть сейчас -- только маленький шаг к тому что должно было бы быть. и.. я согласен с авторами.

>Ну сколько можно велосипеды изобретать?!

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

Очень просто: на сервере для каждого дистрибютива есть список либ и их версии. Если какой-нибудь программе требуется что-то другое, то это другое поставляется в cmg.

Про deb пакет: лично я не знаю как собирать deb-пакеты. Одно время я даже пытался найти информацию на debian.org, но ничего вразумительного и простого не нашёл. В тоже время я без особых проблем напишу rpm-пакет.

.deb -- только для debian'a. Это понятно, надеюсь? Дебиан есть не у всех, это аксиома. Только из-за того что пользователь не умеет, не хочет возиться со сборкой программ не делает его менее полезным тестером его любимой программы.

> Про deb пакет: лично я не знаю как собирать deb-пакеты. Одно время я даже пытался найти информацию на debian.org, но ничего вразумительного и простого не нашёл.

Не найти Debian New Maintainers' Guide это надо суметь. Вопросов больше нет.

> с гномом все кажется сложнее, но что тут было сказано за кривые поделки? :-)

А аргументированно можно? Или все-таки почитаешь сначала о совместимости библиотек GNOME?

> А аргументированно можно? Или все-таки почитаешь сначала о совместимости библиотек GNOME?

для упрощения ситуации беру свои слова назад -- действительно недостаточно компетентен в этом вопросе. (но мне попадались прожки которые не хотели работать с gtk 2.6 будучи собранными с gtk 2.4; названий -- честно скажу -- не помню)

> кстати, рекомендую почитать про смысл и философию этой задумки:
> http://klik.atekon.de/docs/?page=Philosophical%20articles

В общем-то для KDE _приложений_ напрашивается что-то вроде cpan для Perl, pears для PHP и gems для Ruby. Почему бы и нет.

Недавний пример. Я не испытывал много счатья, собирая kaffeine-0.7 (из-за новых фич и отсутствия в Сизифе). Пришлось исправить несколько makefile'ов. Ладно, не в первой, но для нормального пользователя это уже практически не преодолимая задача. Опять же, это отняло некоторое количество времени. Если бы Сизиф поддерживал klik я бы не задумываясь скачал бинарник, всесто того чтобы тратить своё свободное время.

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

Почему же, нашёл. Я там не нашёл _краткого_ что да как. Посмотрите, например, описание для разработчиков ALT Linux Sisyphus. Желание узнать как там это делается было не настолько сильным чтобы сидеть и разбираться в невнятном тексте.

> Я там не нашёл _краткого_ что да как.

dh_make

Но вам это не поможет.

> В общем-то для KDE _приложений_ напрашивается что-то вроде cpan для Perl, pears для PHP и gems для Ruby. Почему бы и нет.

..что не решит проблем с зависимостями и общения с системным менеджером пакетов (ни cpan, ни gem так и не умеют записывать установленные пакеты в системную базу)..

а klik -- это немножко не то. тем более что к kde непосредственно оно отношение имеет небольшое.

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

нет, не совместивый дистрибутив, а систему той-же архитектуры с некотором базовым набором предполагаемых системных библиотек. в этом-то и прелесть, в этом и отличие от отправки по мылу разнообразных deb-ов, rpm-ок и прочего.

звучит просто суперски

--седайко стюмчик

> а систему той-же архитектуры с некотором базовым набором предполагаемых системных библиотек. в этом-то и прелесть,

Воистину. "Некоторый базовый набор предполагаемых системных библиотек" это такая пррэлесть... Хоть на anekdot.ru отправляй.

> Воистину. "Некоторый базовый набор предполагаемых системных библиотек" это такая пррэлесть... Хоть на anekdot.ru отправляй.

:-) опять-таки: вам шашечки или ехать?

предполагаем что у юзера есть glibc + qt + kdelibs. есть? есть.

предполагаем что у юзера есть glibc + gtk2 + libxml2. есть? есть.

это для делателей готовых cmg. протокол klik: предполагает (в нынешнем исполнении) наличия некоего искусственного интелекта основанного на названии дистрибутива. рекомендую поставить и посмотреть на $HOME/.klik

> предполагаем что у юзера есть glibc + qt + kdelibs. есть? есть

По поводу предположений, а ка вы думаете:

qt у пользователя собрана gcc2 или gcc4? Мультитредная или нет? С поддежкой исключений или без них? Ы?

А предположить можно много чего...

> Java WebStart? :-)

Или как .NET сборки? ;-)

> qt у пользователя собрана gcc2 или gcc4?

gcc2.95? :-)

а на счет 4 -- там разве что-то сломали? (просто не знаю)

> Мультитредная или нет?

они даже называются по разному. но -- libqt-mt.3.so

> С поддежкой исключений или без них? Ы?

с ними. впрочем на бинарную совместимость это влиять не должно.

вообще, большинство дистров собирают базовые библиотеки по шаблону, делая их вполне себе совместимыми. кроме того, многие дистры предлагают ставить набор библиотек для обратной или межархитектурной совместимости (как например emerge emul-linux-x86-qtlibs на x86_64).

Идея неплохая. Посмотрим что получится

блин... deb да deb.
tgz рулит.
slackware рулит.

Идея довольно заманчивая! Ндо попробовать.

ищщоб под гном такое. Жаль только что всегда находятся ретрограды которые говорят: "Нах это нужно, мы уж лучше по старинке...и.т.д". И хорошо, что их мнение ни на что не влияет.

Не пойму, в чем прикол-то?

Что полезного в том, что обычные deb'ы из testing превратились
в хрен-знает-что?

> .deb -- только для debian'a. Это понятно, надеюсь? Дебиан есть не
> у всех, это аксиома.

$SUBJ -- тоже только для Debian (KNOPPIX, Linspire, Xandros, KANOTIX --
это все тот же Debian unstable; а Ubuntu -- это fork Debian'а).

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

Дык apt для чего нужен?

> применительно к файрфоксу это означает:

> 1. качать и компилить (руками, ибо emerge super-latest-firefox затрет системный 1.0.6)

а в chroot'е это никак нельзя сделать?

> 2. качать бинари с мозиллы.орг и надеяться что они заведуться с произвольного места (ибо в файрфоксе реестр _есть_)

Безнадежно.

> 3. или скачать один .cmg, про который известно что он работает.

Или поставить нормальный deb-пакет (из которого оный .cmg и получился).
Для "только посмотреть" можно завести chroot с base system и в нем
поставить.

> ищщоб под гном такое.

оно перпендикулярно к гному и кде. надо только посмотреть на инсталляционный скриптик на предмет как оно себя к типам файлов цепляет и будет оно под гном.

> Что полезного в том, что обычные deb'ы из testing превратились в хрен-знает-что?

это не дебы.

> $SUBJ -- тоже только для Debian

вызывающе неверная информация.

> Дык apt для чего нужен?

:-) что бы ставить пакеты, правильно?