установка программ в Линукс (в сравнении с Мак ОС Х)

[starik]

С Линукс не все так - он гибко настриваемый и модульный - как правило, вы можете из одной коробки собрать как инсталляцию для слабенькой машины с минимумом функций, так и "расширенный комбайен с вертикальным взлетом все случаи жизни". Соответсвенно количество библиотек и программ у вас может разнится даже на один-два порядка (10-100 раз) в каждом случае.

гибкий, модульный, на слабую и мощную машину из одной коробки это все обобщенно. А в реальность есть к примеру коробочная версия той же СуСе, так вот на какую нибудь слабенькую машинку засунуть ее будет весьма проблематично, т.к. из коробки она идет КДЕ или Гном которые требуют ресурсов, а другие оболочки по дефаулту в СуСе не идут. Тоже самое и с др. дистрибутивами. Так почему бы например тоже не ввести какой то стандарт к примеру внутри одного дистрибутива с обязательным наличием определенного перечня библиотек, что бы пишушиеся под данный дистрибутив программы не таскали с собой лишние библиотеки (зависимости) - думаю это применимо к Десктоп дистрибутивам, которые хотят пробиться на домашние компьютеры обычных пользователей.

[starik]

Aectann Возникает закономерный вопрос: а многим ли это нужно? Потому и нет готовых реализаций (либо есть, но малоизвестные).

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

[Denjs]

Возможно starik-у будет это так-же интересно: Создание локального репозитория или среза для бубунты: http://aidsoid.org/?p=7

В принципе, процесс создания метапакета, можно приравнять к созданию среза репозитория, ориентированного на поддержку заданной программы.
Осталось поковырять debmirror на предмет отслеживания зависимостей.

для сузи или rpm попробую поискать попозже.

[diesel]

С Линукс не все так - он гибко настриваемый и модульный - как правило, вы можете из одной коробки собрать как инсталляцию для слабенькой машины с минимумом функций, так и "расширенный комбайен с вертикальным взлетом все случаи жизни". Соответсвенно количество библиотек и программ у вас может разнится даже на один-два порядка (10-100 раз) в каждом случае.

гибкий, модульный, на слабую и мощную машину из одной коробки это все обобщенно. А в реальность есть к примеру коробочная версия той же СуСе, так вот на какую нибудь слабенькую машинку засунуть ее будет весьма проблематично, т.к. из коробки она идет КДЕ или Гном которые требуют ресурсов, а другие оболочки по дефаулту в СуСе не идут. Тоже самое и с др. дистрибутивами. Так почему бы например тоже не ввести какой то стандарт к примеру внутри одного дистрибутива с обязательным наличием определенного перечня библиотек, что бы пишушиеся под данный дистрибутив программы не таскали с собой лишние библиотеки (зависимости) - думаю это применимо к Десктоп дистрибутивам, которые хотят пробиться на домашние компьютеры обычных пользователей.

если мы собираем пакет для данного дистрибъютива - мы прописываем зависимости этого пакета от пакетов которые есть в стандартном репозитории. в чем проблема?

[Denjs]

гибкий, модульный, на слабую и мощную машину из одной коробки это все обобщенно. А в реальность есть к примеру коробочная версия той же СуСе, так вот на какую нибудь слабенькую машинку засунуть ее будет весьма проблематично, т.к. из коробки она идет КДЕ или Гном которые требуют ресурсов, а другие оболочки по дефаулту в СуСе не идут. Тоже самое и с др. дистрибутивами.

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

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

[Olegator]

А в реальность есть к примеру коробочная версия той же СуСе, так вот на какую нибудь слабенькую машинку засунуть ее будет весьма проблематично, т.к. из коробки она идет КДЕ или Гном которые требуют ресурсов, а другие оболочки по дефаулту в СуСе не идут

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

и ещё куча шаблонов в ясте

[starik]

Возможно starik-у будет это так-же интересно: Создание локального репозитория или среза для бубунты: http://aidsoid.org/?p=7
Весь репозиторий занимает около 20-30 Гигабайт

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

[starik]

если мы собираем пакет для данного дистрибъютива - мы прописываем зависимости этого пакета от пакетов которые есть в стандартном репозитории. в чем проблема?

так проблема в том и есть, что в репозитории а не вдистрибутиве. Вобщем всем спасибо, все таки нехотя но понимаю, что у линукс в мире ОС как и у России государства свой особы путь развития, чем мы Россияне (или некоторые из них) и гордимся

[Olegator]

у России государства свой особы путь развития

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

[starik]

ладно, спасибо, всем счастливо...

[shade1387]

По незанию спрошу: а как обновлять установленные программы в макоси?

[Olegator]

По незанию спрошу: а как обновлять установленные программы в макоси?

как как? на рабочем столе лежит ярлык, его перетаскиваешь на ярлык в виде компьютера и вот идёт обновление

[diesel]

По незанию спрошу: а как обновлять установленные программы в макоси?

аналога aptitude upgrade нет, хотя KiWi давал ссылку на AppFresh, который умеет следить за обновления того что установлено, а так - каждая уважающая себя программа при запуске проверяет нет ли новой версии, и если есть - предлагает апдейдится. Это, с точки зрения линуксоида, скорее всего выглядит неудобным, из-за отсутствия централизованной системы обновления, но по большому счету ничего принципиально страшного в этом нет. Система следит за своими апдейтами сама, а программы, которые часто используются на десктопе - можно по пальцам пересчитать.

[minoru-kun]

Denjis, есть же apt-zip.

[Samae1L]

Кто не знает как происходит установка в Мак ОС Х вот ссылка видео ролик (размер 6.6 Мb)

ну и гемморой
то ли дело в Дебьяне - запустил Синаптика, тыцнул мышкой по флажку и нажал "Установить"
----------------
кстати, в этом ролике я первый раз увидел, как работают с маковским интерфейсом, и, скажу я вам, меня что-то подташнивать от этого начало. Какое-то всё блестящее, пёстрое, невыносимо эффектное. Для домохозяек, в общем. Серьёзно работать на этом невозможно, ИМХО

[Goodvin]

кстати, в этом ролике я первый раз увидел, как работают с маковским интерфейсом, и, скажу я вам, меня что-то подташнивать от этого начало. Какое-то всё блестящее, пёстрое, невыносимо эффектное. Для домохозяек, в общем. Серьёзно работать на этом невозможно, ИМХО

На вкус и цвет фломастеры разные.

[VAA]

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

В линуксе и этот подход есть, в пределах одного дистрибутива

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

Почему в таких экзотических случаях не все зпихнуто в один пакет? А бывает и запихнуто. Ну, скажем, у скайпа есть вариант пакета со статической сборкой. Пакет получается большим, но зато не зависящим от дистрибутива.

А тут еще одно обстоятельство: линуксов много разных, а макОС одна(!) пропиетарная, это только один из юниксов, ее собирает ТОЛЬКО ОДНА фирма, как и Винду, и поэтому состав включенных библиотек жестко известен. А самодельщиков, с ихними пакетами с нестандартными зависимостями, к ней стараются не пускать. Но зато допущенные к столу профессионалы хотят взять деньги. И не малые, иначе мощи не хватит поддерживать все это хозяйство в образцовом порядке (слабосольные конкуренты померли ).

Имеете право выбора: платить за понравившийся Вам в макОС порядок (вполне обосновано, кто наводит порядок - должен за это деньги получать!) или пользоваться тем, что кажется Вам бардаком в линуксе, но бесплатно.

"Думайте сами, решайте сами, иметь или не иметь... "


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

[mandrivauser]

Аналогично. Тоже в Маке ничего не понял.

Видимо, разобраться в интуитивно понятном интерфейсе можно только с помощью хорошей интуиции

В то же время, когда переходил с винды на Линукс - сразу как-то все понял.

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

[Denjs]

Denjis, есть же apt-zip.

Как я понял apt-zip заточен на обновление. А тут нужно не обновление а составление и складывание "грозди зависимостей".

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

описание и пример: http://www.lexpr.ru/node/296

разъяснения к примеру использования (судя по всему - это то что нужно):

<...>Здесь rpmfind ищет в локальной системе exmh, но поскольку пакет не установлен, утилита проверяет базы на http://rpmfind.net, и далее делает две вещи: находит пакет, и находит зависимость пакета - nmh. После повторной проверки и установления факта, что nmh также отсутствует в локальной системе, утилита спрашивает, следует ли выкачать также зависимости, ... <...>

а вообще это был кусок из "Red Hat RPM Guide - русский перевод"

не понятно только как её заставить складывать пакеты в заданный каталог, как её подсунуть нужные мне репозитарии и т.п.
Но думаю там по традиции есть какой ini-шник? ^_^

[AlexVedun]

А как насчет Autopakage? По-моему это и есть те самые метапакеты.

[starik]

AlexVedun Дата Вчера, в 19:49
А как насчет Autopakage? По-моему это и есть те самые метапакеты.

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

[izen.fire]

у Linux есть идеология и стандарты, определяющие места в системе, по которым эти файлы "раскидываются". Эти стандарты пока всех устраивают, и не надо делать из linux игрушку для домохозяек.

Есть стандарт "Linux Standard Base" и общий для всех "XDG". Пока что LSB, в отличии от XDG, не получил одобрения у дистростроителей. Есть лишь ДЕТАЛИ общих стандартов в конкретных популярных дистрибутивах, но не всё вместе.
Смотрите ещё, сколько слабо совместимых между собой схем дистрибуции ПО выкатывают: контейнеры .deb, .rpm, .tbz, .ebuild'ы, неговоря уже о контейнерах .bin. Приходится пользоваться alien, чтобы адаптировать ПО из RPM в DEB и нормально установить его в системе с прописанными зависимостями.

[izen.fire]

то ли дело в Дебьяне - запустил Синаптика, тыцнул мышкой по флажку и нажал "Установить"

Не всё так просто. Пакеты .deb не всегда содержат полностью готовое ПО, каким оно видится разработчику этого ПО. Мантейнеры Debian оставляют за собой право дробить авторское ПО на слабозависимые пакеты и выкладывать в репозиторий, перекладывая заботу о разрешении проблем неработоспособности на пользователя. Хороший пример: Sun JRE 6.0 в репозитории Debian и Ubuntu разбито на несколько пакетиков, некоторые из которых "рекомендованные", но не обязательные к установке; когда пользователь решит установить Java на свой компьютер, то он скачает и установит лишь базовые DEB-пакеты, поддержка ввода на национальных языках в которых отсутствует; пользователю самому нужно думать, каким образом включить поддержку, хотя в авторском варианте дистрибуции Sun JRE (standalone international) включена такая возможность изначально — пользователь Debian и Ubuntu в странах отличных от США сразу оказывается в ситуации НЕРАБОЧЕГО ПО из-за "рекомендуемых, но необязательных" к установке пакетов == "домысливай сам, что нужно доустановить и сделать, чтобы всё заработало".

[izen.fire]

вот как раз на этапе "Готового... не предложу,....Полагаю, что придется для этого писать скрипт ... Вполне решаемо." все и заканчивается.

Возникает закономерный вопрос: а многим ли это нужно? Потому и нет готовых реализаций (либо есть, но малоизвестные).

В PC-BSD сделали PBI-систему, которая собирает в один пакет дистрибуции само приложение и все его зависимые библиотеки. Приложение устанавливается в отдельный каталог (как в Windows). Нету проблем с версиями библиотек — приложение использует именно те версии, с которыми распространяется.