LINUX.ORG.RU
ФорумTalks

Из искры возгорится пламя! :-)


0

0

Аксиома администрирования Linux (да и весь Unix-подход к управлению системой) гласит, что надо делить мух от котлет - то есть программы от данных. Классические пакетные менеджеры (dpkg, rpm и прочие) обеспечивают прекрасную поддержку этой парадигмы - есть программа (пакетный менеджер) и есть данные (пакет, который надо установить в систему). Соответственно, инсталятор всегда будет соблюдать все заданые правила и поддерживать порядок в системе, обеспечивая ее стабильность.

В противовес этому, в Windows пакет и инсталятор суть одно и то же, и каждый пакет должен сам заботиться о себе. Следствием этого является чрезвычайно высокая "самостоятельность" инсталяторов, которая приводит к тому, что система "разбухает" и содержит кучу хвостов, которые непонятно откуда взялись, а при деинсталяции ничем кроме "джентльменских соглашений" не связаные пакеты могут легко вынести не только себя, но и кусок системы.

Вследствие этого появилась странная мысль: сборка программ из исходников с установкой их через make install (то есть минуя полнофункциональный менеджер пакетов), а также создание инсталяторов "сам себя как надо поставлю" [типа инсталера Oracle или firefox'а с официального сайта] - это прямой путь, который превратит Linux в Windows в ее худших проявлениях!

★★★★★
Ответ на: комментарий от JB

> ты представь сколько он весить будет ;) десятки пакетов для кучи дистров...

совсем не обязательно; вместо этого он может просто перепаковать архив в нужном формате в процессе "инсталляции", вроде того как это делает драйвер ATI. что впрочем тоже не сахар.

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

вывод -- нахрен никому из дистростроителей не нужен посторонний софт.

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


>Угу, глянь чего требует frozen-bubble например.

вот, какие пакеты я установил в Slackware 10.2 чтобы поиграть в него

frozen-bubble-1.0.0-i486-4pin.tgz
perl-sdl_perl-1.20.0-i486-2pin.tgz

и?

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

>У меня слака на работе. Ацтой ацтоем!

IMHO забыл, родной :)

IMHO, suse "Ацтой ацтоем" - последний раз пробовал 9.3 - тормозила, глючила по сравниению со слакой и убунтой на том же железе ;)

Еще на одном старом лаптопе пробовал поставить(IP233MMX) - дык, там инсталлер дох, пока не плюнул на эту зюзю ;)))

AcidumIrae ★★★★★
()

>Вследствие этого появилась странная мысль: сборка программ из исходников с установкой их через make install (то есть минуя полнофункциональный менеджер пакетов), а также создание инсталяторов "сам себя как надо поставлю" [типа инсталера Oracle или firefox'а с официального сайта] - это прямой путь, который превратит Linux в Windows в ее худших проявлениях!
Про огнелис - а разве в дистрах он не распространяется в родных пакетах?
За OCFS и RAC Эллисону можно простить практически всё. А за жабу в базе оторвать тоже практически всё :-)
P.S. Из ораклового инсталлера в течении часа создается пакет под требуемую (поддерживаемую!) платформу. При наличии оной. Без шуток.

sco-killer
()
Ответ на: комментарий от Inoq

> перенос процесса компиляции с девелопера на энд-юзера

Не на юзера, а на штатные средства дистрибутива. Вмешательство юзера в процесс компиляции требуется крайне редко (и является признаком недоработки мэйнтейнеров пакета).

anonymous
()

А батарейкин таки ламер?
Он ничего не знает про статическую и динамическую сборку?

Читать просто смешно.

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

Если Slackware это помойка, то как тогда обозвать любой rpm-based дистр, где кроме make install и глючных костылей типа checkinstall нет способов собрать и поставить свой пакет (написание .spec даже не упоминаю, ибо никто не будет трахаться с этим, а просто сделает make install)?

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

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

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

>>написание .spec даже не упоминаю, ибо никто не будет трахаться с этим, а просто сделает make install
Ну, если кому трудно руками спек написать - пусть откроют для себя krpmbuilder.
Он хоть и корявый - но "рыбу" для спека делает нормальную, дальнейшая доработка по вкусу.

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

> написание .spec даже не упоминаю, ибо никто не будет трахаться с этим

мне нравится как всякие долбоклюи обобщают свои долбоклюйские выводы на всех -- ни много ни мало :)

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

спек для не очень большого пакета пишется за час -- с проверкой и так далее. а ты сиди дальше посреди зловонной кучи :)

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

make install это лучший способ засрать систему. Но вообще есть installwatch который умеет делать rpm. Для совсем уж ленивых и криволапых ламиров.

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

>спек для не очень большого пакета пишется за час

ЗА ЧАС??? Пипец! И кто из нас после этого долбоклюй? Ладно, пиши свой спек, а я сделаю makepkg и через пару секунд получу готовый пакет.

>а ты сиди дальше посреди зловонной кучи

Ты чё мудак? Какой кучи? У меня ВСЁ собрано в пакеты и нет НИЧЕГО поставленного методом 'make install'! (В отличие от тебя. Сомневаюсь, что ты трахаешься часами в написании спека для установки какой-нибудь херни).

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

> Компиляция на машине энд-юзера это трата времени юзера

Что за? Еще раз повторить что-ли: юзер в процессе компиляции участия не принимает и времени, соответственно, не тратит.

> и расточительный расход машинных ресурсов.

Так энд-юзер сам сделал такой выбор. Видимо выгоды перевешивают недостатки.

> Если для пионеров это не важно, то в бизнесе такое недопустимо.

Ну расскажите что-нибудь такое-эдакое про бизнес и пионеров.

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

> Слово "видимо" ты будешь применять при письменном обосновании выбора генты вместо редхата?

Я?

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

>Линукс тоже бывает что и рулит какая разница и у него бывают бинарные >инсталляторы.
Русскую языку не знаем? Или запятые на клавиатуре сломались?

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

> Русскую языку не знаем? Или запятые на клавиатуре сломались?

Это бот.

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

> В рпм-дистрах эта игрушка на несколько сот Кб тянет за собой ещё пару десятков Мб.

А в винде половина игрушек носят с собой directx 33-метровый, и что?

no-dashi ★★★★★
() автор топика
Ответ на: комментарий от no-dashi

То чего требует виндовый софт, можно пересчитать по пальцам и не в падлу поставить ручками. "Зависимости" же в "свободном" линуксе стали притчей во языцах :).

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

> То чего требует виндовый софт, можно пересчитать по пальцам и не в падлу поставить ручками.

ODBC, DAO, ODAC, DCOM, DirectX, IE, кодеки, WMP, MFC, .NET framework, BDE, SFU, Office (чтобы всякие 1С печатали и данные экспортировали), ServicePacks... Плавали, помним, спасибо, не надо!

no-dashi ★★★★★
() автор топика
Ответ на: комментарий от no-dashi

> .NET framework

Причём строго определённый!

> BDE

Который можно поставить лишь одним способом - запустить dll-ку в которую зашит инсталлятор, при этом проверить поставился ли он нет никакой возможности.

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