LINUX.ORG.RU

Стандартный дистрибутив ???


0

0

http://www.osp.ru/text/302/185604.html

Хоршая штука но кажется и она не спасет пока не будет собран реальный дистрибутив в котором будут реализованы все принципы LSB.

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

ИМХО, вся проблема линуксов в способе установки софта. Под каждый дистрибутив свои способы: бинарные (для каждого дистра используются свои пакеты, скомпилированые именно для него) или установка из исходников, например Gentoo. в первом случае могут быть проблемы с установкой стороннего софта, не предназначеного для данного дистрибутива, например несоответствие путей к библиотекам (но это исправимо) или несоответствие версий библиотек. второй способ - установка из исходников, но в ней сложно уместить "базовое ядро системы" в 50МБ, т.к. для компиляции некоторых приложений требуются средства разработки, компиляторы, библиотеки, которые могут по размеру быть в десятки раз больше, нежели само приложение. ИМХО, второй способ лишен недостатков бинарных вариантов, но имеет свои недостатки, связанные со временем компиляции и установкой дополнительного софта, который, впринципе, в дальнейшем не нужен, а нужен лишь для того, чтобы скомпилировать конкретное приложение. Например, для установки из исходников приложения cvsup нужно средство разработки Modula-3, на которой он написан. посему в Gentoo или FreeBSD прежде, чем установить cvsup, нужно сначала установить Modula-3, исходники Modula-3 весят ~30 мегабайт, а исходники cvsup полмегабайта. После установки, Modula-3 лежит мертвым грузом, который больше не для чего не нужен. ИМХО в таких случаях предпочтительнее использовать бинарный способ (который так же доступен в этих системах).

Marmirus ★★
()

Лебель, рак и Gentoo.

> Мне кажется было бы удобно скачать дистрибутив с базовым ядром на 50 мегабайт а потом нужные компонеты добавлять запуском скрипта.

Gentoo?

Camel ★★★★★
()

Билять, уже сил нет. Какие же вы активные, пионеры-изобретатели...

> Мне кажется было бы удобно скачать дистрибутив с базовым ядром на 50 мегабайт а потом нужные компонеты добавлять запуском скрипта.

Откро для себя apt, yum,...

Zulu ★★☆☆
()
Ответ на: комментарий от Marmirus

Волшебное слово, которое перечекривает все сорс-бейзед способы распространения софта -- это воспроизводимость.

На локалхосте можешь онанировать как хочешь, а вот когда из 50 машин у тебя бага будет вопроизводиться на 5, и ты будешь два дня искать, что проблема в том, что одна из библиотек, с которой собрано нужное приложение, собрана сама с разными ключами на этих машинах -- вот тогда поймешь, где место gentoo, freebsd и прочим слакварям.

Zulu ★★☆☆
()
Ответ на: комментарий от Zulu

Кто мешает собрать-таки из сорцов пакет на одной машине и растолкать его на все? Вроде никто. Автоматизируется это скриптом из 10 строчек, говоришь ему на сборочной машинке "собрать порт такой-то" - и он тебе усё соберёт как тебе надо, упакует и растолкает по серверам.

В этой связи противопоставление source-base и binary-based вообще довольно искусственно, пакеты собирать можно и там и там.

Teak ★★★★★
()
Ответ на: комментарий от Zulu

Но, если системы все одинаковые, если все апдейтится одинаково на всех машинах, если я-админ и я знаю, где какие ключи, в чем беда? Если на одной машине я задал флаги компилирую с помощью distcc и раздаю бинари другим машинам. в чем беда?

Marmirus ★★
()
Ответ на: комментарий от Marmirus

Ты по сути хочешь, чтобы все дистрибутивы, кроме одного (объединённого или ныне существующего) были уничтожены. Почему бы так и не сказать? А то прикрываются словом "стандарт"...

Teak ★★★★★
()
Ответ на: комментарий от Teak

Почему бы не стандартизировать сборку из исходников? :) Как это кстати уже сделано например в Autoconf'e - единственно чего не хватает дак это эксплицитного указания зависимостей. В принципе легко добавить еще один ключик к configure, например --show-deps - стандартизируется вывод, а разнообразные инсталляторы его парсят как хотят. Почему нет? Плюс оборачивать вывод --help на предмет --with- и --enable- в меню выбора инсталлятора. Установка легко логируется к примеру такой классной штукой как paco (http://paco.sourceforge.net/). Что имеем в итоге:

- разработчик продолжает делать все что делал раньше (никакой возни с созданием пакетов / ебилдов и прочего)

- отпадает необходимость в сопровождении централизованных репозитариев

- единообразие дистрибутивов программ (то чего так хотят вантузы и 3rd patry developers ) - тарболл :)

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

- возможность гибкого конфигурирования на этапе компиляции (возможно с разумным умолчальными установками либо основанные на глобальном профиле) + сборка под конкретную машину => boost в скорости

- никакой файлопомойки а-ля ./configure && make && make install - все установленные файлы находятся под контролем + все прелести paco (query конкретного файла на принадлежность к пакету, контроль shared-files, учет размера и прочее и прочее, см. paco.sourceforge.net)

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

anonymous
()
Ответ на: комментарий от anonymous

>Почему бы не стандартизировать сборку из исходников? :) Как это кстати уже сделано например в Autoconf'e - единственно чего не хватает дак это эксплицитного указания зависимостей. В принципе легко добавить еще один ключик к configure, например --show-deps - стандартизируется вывод, а разнообразные инсталляторы его парсят как хотят. Почему нет? Плюс оборачивать вывод --help на предмет --with- и --enable- в меню выбора инсталлятора. Установка легко логируется к примеру такой классной штукой как paco (http://paco.sourceforge.net/). Что имеем в итоге:

в итоге имеем Gentoo с USE-флагами

Marmirus ★★
()
Ответ на: комментарий от Teak

я этого не говорил, лишь высказал свое мнение по поводу способов установки софта. Пытался быть объективным. Перечитайте мой пост еще раз (07.01.2007 16:08:33).

Marmirus ★★
()
Ответ на: комментарий от Marmirus

Ага, ты тоже мой перечитай. Вот и поговорили.

Teak ★★★★★
()
Ответ на: комментарий от Marmirus

USE-флаги - это, я как понимаю, жестко заданный список фич, которые будут включаться / исключаться при компиляции плюс возможность для каждого конкретного случая создавать свой список флагов. Это плохо, потому что нельзя предусмотреть все возможные опции компиляции для каждой программы. Способ выборочной установки флагов как он реализован в генту менее удобен чем тот который я предложил - расставить чекбоксы (возможно даже с системой справки) в (псевдо)графическом инсталляторе куда как удобнее чем формировать гигантский список из невразумительных сокращений вроде mp3 alsa whatever. Генту также не рулит по той же причине по которой не рулят другие системы с централизованной системой установки пакетов - если дистростроитель / коммюнити забыл(о) / не пожелал(о) включить ту или иную программу в репозитарий - то облом-с, распаковывайте тарбол (то что _всегда_ есть если есть прога), ну и дальше волшебные ./configure && make && make install, превращайте свою систему в помойку. Это то что бесит вантузов, девелоперов и то что бесило меня когда я перелез с венды :). Я целиком и полностью поддерживаю идею больщих баз данных софта с индексом поиска, сортировкой по группам, возможно даже удаленными запросами и т.п. - типо фрешмита, это очень удобно. Но очень плохо когда список софта который я могу установить ограничивается списком в централизованной базе, это ЗЛО. Ждать ебилды весело, но это тоже зло :)

anonymous
()
Ответ на: комментарий от anonymous

Мои простыни наверное никто не читает :) Нужно писать мало, но с экспрессией или как ВСЛ - постоянно аппелировать к смерти, агрессии в отношении неугодных, своей и единомышленников особости и ничтожности остальных, свою безусловную правоту подкреплять высоконаучными сентенциями... Ооо, чертовски притягательные посты, хочется их читать еще и еще, невзирая на размер :)

anonymous
()
Ответ на: комментарий от Marmirus

> в кадом дистре по-своему (apt, yum, rpm....)

Ты путаешь мокрое с мягким. apt и yum - все. RPM и DPKG работают незаметно для глаза уровнем ниже. Наверное, стоит подучить мат часть прежде чем давать советы.

Shaman007 ★★★★★
()
Ответ на: комментарий от anonymous

> Почему нет?

Потому, что когда скрипт "стандартно" станет решать от чего зависит компилируемый софт наступит апокалипсис. То, о чем ты говоришь реализовано в gentoo.

> - отпадает необходимость в сопровождении централизованных репозитариев

на всех 1 мораль и 1 патчсет?

Shaman007 ★★★★★
()
Ответ на: комментарий от Teak

А воспроизводимость с другими людьми? У тебя не работает, у остальніх работает.
Блин, вы что, все локалхосты админите? Не натыкались на грабли никогда?

Zulu ★★☆☆
()
Ответ на: комментарий от Marmirus

> Но, если системы все одинаковые

никогда так не будет.

> если все апдейтится одинаково на всех машинах, если я-админ и я знаю, где какие ключи, в чем беда?

В сменщике. В дежурных. В подчиненных. Во всех кто в это замешан. Если ты один-единственный человек на одной-единственной машине, то ты мне не интересен. Хоть вприсядку дрочи.

Zulu ★★☆☆
()
Ответ на: комментарий от Shaman007

> Потому, что когда скрипт "стандартно" станет решать от чего зависит компилируемый софт наступит апокалипсис.

"Стандартно" ровно настолько, насколько сейчас это делается autoconf

> То, о чем ты говоришь реализовано в gentoo.

К сожалению, основная идея осталась непонятной

> на всех 1 мораль и 1 патчсет?

Мораль такая - надлежащим образом оформлять исходники прежде чем выкладывать на паблик. Никто ведь (за исключением редких случаев) не компилит и не линкует каждый файл в отдельности, верно? Потому что договорились _стандартно_ использовать make. Требуется-то всего-ничего - явное указание зависимостей где-нибудь среди дистрибутива. Я не знаю как это конкретно может быть реализовано - может быть на манер _стандартных_ README-образных плоских текстовых файлах, либо как вывод _стандартного_ ./configure расширенного ключем --show-deps.

Еще бы мне хотелось чтобы по дефолту конфигурационный скрипт выводил список фич с которыми будет собрана софтина. Почему некоторые этого не делают, это же так просто?

anonymous
()
Ответ на: комментарий от anonymous

>Минусы - нужно иметь на клиентской машине комплект разработчика + долгое время компиляции

Эти так сказать "минусы" вообщем то являются решающими при выборе пользовательской платформы.

ssizziff
() автор топика
Ответ на: комментарий от Zulu

Да гемор это все. япт ямп маке ... Рутина которая отнимает кучу времени, нервов, а зачем??? Зачем мне десять способов поставить ОДНУ программу???

Колупаться десять часов в исходниках, отлавливать связи, компилировать пять часов исходники что бы в результате понять что программа была ненужна. Уже symbian скоро обгонит линукс по популярности :(.

ssizziff
() автор топика
Ответ на: комментарий от ssizziff

> Рутина которая отнимает кучу времени, нервов, а зачем???

Последнее поступление мозговых слизней идет по соблазнительной цене, не упусти свой шанс, чучело!

anonymous
()
Ответ на: комментарий от Zulu

> В сменщике. В дежурных. В подчиненных. Во всех кто в это замешан. Если ты один-единственный человек на одной-единственной машине, то ты мне не интересен.

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

mutronix ★★★★
()
Ответ на: комментарий от Zulu

> Не натыкались на грабли никогда?

На такие, как ты говоришь - нет. Вот нет и всё тут. Хотя на серверах в основном фрюха, причём порты собираются на самих серверах даже (хотя конечно всё одинаково и почти стандартно).

Teak ★★★★★
()
Ответ на: комментарий от Teak

Вот значит хорошо тебе.
А я вот сталкивался с разным нехорошим.

Zulu ★★☆☆
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.