[Comm] Re: [JT] [OT] Re: 0install

[Arioch]

Michael Shigorin пишет:

AAS: почему-то talk-room так и не появилась на GMane'e, а тема прямо 
туда скатывается :-(

AS: я не считаю 0install идеалом, но и критика репозиториев мне кажется 
убедительной. Из опыта этого велосипеда вполне может родиться что-то 
совершенно естествнное завтра. Из тысячи велосипедов 999 отмирают. Но 
остается и тот один... :-)

> Это такая же демагогия, как у автора 0install, уж простите.

Частично. Проломы репозиториев намного реже, зато последствия намного 
хуже. Общие места в спорах централизация-или-сеть

>>Только загрузка аптового индекса дооолгая, однако :-)
> Это зависит от объёма репозитория. 

Я не про download, а про загрузку в программы типа apt-get, Synaptic.
Если Синаптиком надо поставить пакет размером в считанные килобайты, 
типа zlib, то download почти моментальный, а вот перечитывание дерева...
Равно и фиксация/освобождение пакетов, хотя это возможно больше вина 
Синаптика (или меня, не умеющего Синаптиком несколько пакетов за раз 
фиксировтаь)

Можно сказать, что пользователю полезно будет подумать полчаса и 
определить по разным признакам те пакеты которые ему будут нужны и потом 
поставить сразу. Это не всегда легко/удобно/нужно.

> велосипедики не прекращают шустрить, как только задачи начинают
> отличаться от "две софтинки, три пользователя в мире"?

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

Но вопрос реализации и вопрос идеи - немножко разные.
Я на Сизифе совсем недавно, и то на моей памяти Синаптик как-то вдруг 
стал быстрее раза в три загружаться :-)

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

Вылизать можно то, что в основе достаточно хорошо ложится.
А насчет этого есть разные мнения.

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

Тогда же я слышал, как это круто, что каждый юзер может поставить 
программу любую в HOMEDIR и не мешать остальной системе (и как следствие 
   не теребить администратора) - и это верно.
Но для тех кому нужно настроить сетевой сервер раз на три года, и где 
все его программы существуют либо для самого админа, либо для кучи 
народа по сети (т.е. существуют не для конкретного юзверя, а в системе 
вообще) - это непонятный и не нужный каприз. Типа для клиентов и винда 
сгодится.

Но на таких серверах не нужен и drag-n-drop, hal и весьма большая часть 
всех новинок последних двух лет. ОДнако они есть - потому что многим 
другим нужны.


>>Я исключительно-юзерские - во-первых нужно найти rpm,
>>подходящий к дистру, во-вторых потенциально дублируются
>>бинарники для каждого юзера.
> 
> Так эти проблемы не решаются 0install.  Зато определённо
> создаются.

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

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

Наконец, я не знаю можно ли мне через apt-get или Синаптик поставить без 
пароля рута себе Gimp. М.б. rpm и сумеет, там руководство безбрежное :-)
Но простому юзеру едва ли нужно прорываться через 100-ню непонятных 
страниц, чтобы потом думать где взять rpm-ку, как у нее с зависимостями 
и где брать rpm-ки для зависимостей, и каких сборщиков rpm-ки ему выбрать.

>>>Потому что "without even checking the original sites for
>>>updates" гарантирует то, что все дырки -- у пользователя,
>>>который не занимается с утра до ночи перекэшированием
>>>натянутого и используемого барахла.
>>
>>Чем это отличается от,например, Сизифа?
> 
> Интегральностью операции обновления и

Нужной для разрешения зависимостей rpm ?

Что за дырки имеются ввиду? Если баги в программах, то при чем тут ?

 > автоматизируемостью проверки статуса.
...если пользователь занимается с утра до ночи перечитыванием списка 
пакетов в репозитории.


> Hint: и здесь эта хрень тоже ничем не помогает. 

Помогает, ибо если автор собрал прогу в linux/i586 то ее можно 
использовть уже в любом дистре под x86

> Попробуйте?
[skipped]
> и немало помогают интегрировать ПО, а не держать лоскутный
> коврик.

На каждом уровне свое. Не все программы стоят таких усилий.
Я, конечно, провокатор, но ведь с какой-то точки зрения и LSB лоскутный 
коврик по срвнению с LFS. Полу-шутка.

> Вы попробуйте на досуге скрестить RH7.3 и RH9, а там продолжим..

А если они (и софтинки из примера) общаются исключительно по TCP ?

>>ЗАто можно запустить сейчас и начать неспещно пиать автора
>>насчет апгрейда :-)
> 
> Я бы при подобном пинании послал далеко и решительно.

Типа
юзер: "давно вышел glibc 2.3, зачем вы компилируете под 2.2" ?
вы: "А мне так нравится, у меня все под 2.2"

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


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

Каша - это когда все ббиблиотеки - latest stable vanilla ?

Ну тогда система поскрипит, и в дополнение к glibc 2.3 специально для 
вашей программы скачает устаревшую 2.2, по крайней мере так обещали.

> Да, уже перечитал и ту часть повнимательней.  Стало много
> веселее: один пользователь может устроить засаду другому,
> поставив заведомо нерабочую версию. :]

Если подложит в кэш нерабочую версию и не даст другому юзеру обновить 
кэш. Потенциально такая проблема есть. Вопрос в том, насколько 
эффективно распознавание подделок и обновление будет реализовано в этой 
p2p.


> Вообще это модель безопасности, напоминающая чем-то /tmp.
> А /tmp -- это одна из фундаментальных грабель в UNIX.

Особенно если подломать программу SUIDящуюся в рута :-)

Хотя и прочитать дневник/почту/органайзер другого человека тоже неприятно.

>>>>Неформализуемые скрипты в rpm, работающие от рута - это
>>>>действительно проблема.
>>>
>>>И где это проблема, если код, который устанавливается, также
>>>неформализуем? 
>>
>>Код может никогда не выполняться от рута.
> 
> Да.  А rpm можно проинструктировать не выполнять скрипты и
> триггеры.  Ну и?

Ну и кто так делает для практических задач? А можно rpm просто 
распаковать по файлику. Или скачать исходники и собрать их попробовать 
(назад к истокам и lfs).

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

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

>>и насчет кто-куда-зачем
> 
> Не обнаружил ничего интересного и _формализованного_.

Там этого и нет, согласен. Я не уверен, что строить систему на основе 
self-contained программ, целиком в одной папке, это хорошо.
Так, поползли в философию :-(

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

Все потенциальные преимущества 0install можно по отдельности не считаясь 
со средствами реализовать над тем же rpm. Вот только будет это насилием 
над сложившейся системой и потому будет слишком затратно.


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

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

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

На том что авторы, а именно они (и сложившееся вокруг них ядро 
компиляторов под другие архитектуры) предполагаются источниками 
бинаринков, как люди понимающие (программисты) и активные(иначе бы не 
писали), едва ли будут сидеть на позапрошлых стабильных релизах.
Они лучше простых пользователей понимают преимущества например glibc 2.3 
над 2.1 :-) Потому авторы, в массе, вполне возможно, будет сидеть на 2.2 
(stable - 1) с изученными и знакомыми глюками, но не на 2.1 (stable - 
2). И за собой потянут юзеров.



>>Случаи bug-compatibility под конкретную сборку библиотеки в
>>принципе можно заложить в систему, хотя бы просто статическим
>>линкованием или положением библиотеки в одну папку с
>>программой.
> 
> Трёп.  Кто этим будет заниматься?

Извращенец, заложивший b-c в свою программу.

>>Опять же, сам вспоминал пример с glibc 2.2 и 2.3
> Это не bug compat.  Это slow migration, причём с поводом.

Почему они могут сосуществовать в repos-based  и не могут в cache-based ?

допустим, автор AppXXX-1.2 зависит от LibYYY-3.4, а она от glibc 2.2
Потом LibYYY-3.5 зависит от glibc-2.3. Автор либо остается на LibYYY-3.4 
  либо тоже переходит на glibc 2.3

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

> PS: выгоняйте меня в talk-room@ :)
> 
Ага, дамоклов меч над не скажу чем.

Я как сюда зашел, подписал несколько листов на NNTP-gate gmane. И вот 
например community-english появился, а talkroom или например legal - не 
хотят. Или у меня Thunderbird глючит? черт, определенно глючит, ведь из 
Outlook Express я уже в легал писал, кажется!
(3 минуты спустя) да, это была птица...

Я честно говоря не знаю, что из этого разговора выйдет кроме "время 
покажет", и "для целей, близких лично мне, этот проект [не]нужен"
Но если не надоело, пошли в talk-room. Я не могу поставить Follow-Up с 
NNTP стороныю :-(