/nix/store/r8vvq9kq18pz08v249h8my6r9vs7s0n3-firefox-2.0.0.1/

Еще один xstow?

Если бы в линуксе была реальная конкуренция (на десктопе ее точно нет), то все бы так хорошо и работало.

Но и один-единый пакетный менеджер-стандарт - тоже не лучше.

Лучше. Точно так же, как и одно ядро с большим количеством настроек. Часто забывается, что ОС не имеет никакой ценности сама по себе, главное — приложения.

Костыли для инвалидных колясок..

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

Вообще интересно, если кто-нибудь смог бы оценить основные существующие пакетные менеджеры (даже с учетом «хаков») по критериям:

• Производительность как непосредственно сборки из исходников, так и работы с бинарными пакетами. Как то: установка, обновление, удаление, очистка, поиск, подготовка бинарников и пр.
• Удобство и интелектуальность, т.е. кол-во действий при администрировании для достижения желаемого результата.
• Функциональность - кол-во операций, которые пакетный менеджер может выполнить над пакетами или группой пакетов.
• Гибкость управления, т.е. кол-во вариаций получаемых пакетов - точность подгонки под конкретные задачи.
• Оптимизация. Учитываем кол-во операций, необходимых для подготовки оптимизированных бинарников с помощью пакетного менеджера для имеющегося в распоряжении железа.
• Автоматизация. Удобство использования менеджера в командной строке.
• Наличие gui для простоты управления неопытными пользователями.
• Количество имеющихся на текущий момент актуальных пакетов (1 программа - 1 пакет без вариаций), созданного для данного менеджера с учетом отсева устаревших программ.
• Универсальность - кол-во форматов пакетов, которые можно установить, с помощью менеджера.
• Кол-во мусора, оставляемого менеджером после установки-обновления-удаления пакетов.
• Кол-во нерешенных задач пакетным менеджером. К примеру, я не знаю ни одного примера автоматизированного создания базы знаний для формирования пакетов установки на основе исходников.

Что-то подсказывает, что сейчас, даже с учетом еще нереализованных возможностей и кучей недостатков, portage будет на первом месте, palludis на втором. Поправьте, если не так;)

чуваки а сделалйте закрулялки уголков аватарок. гламурненько как на iphone

это патентованная технология

схема? своеобразный выбор, но буду следить

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

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

юзеры просто не хотят использовать gentoo?

Portage не конкурент Nix'у и Guix'у.

Portage/Palludis совсем не замена Nix'у и Guix'у. Почитайте как Nix устроен. Вопросы отпадут.

портаж не имеет тех возможностей, которые имеет nix

А разве наоборот не будет также справедливо? Никс умеет готовить бинарники только с нужным функционалом?

Если честно, я впервые слышу о подобных менеджерах пакетов, а о работе без привилегий рута чуть ли в обморок не упал. Можете кто-нибудь в крациях рассказать про функционал менеджера: что он из себя представляет - сборку программ из сорцов напрямую после получения, или получение скомпилированных с репозитория дистрибутива?, если второе, то что из себя будет представлять пакет ? - распределенный по нескольким категориям, ну типа библиотеки, доки, либо бинарники, или всё сразу - воедино? Извините за нетерпеливость :)

Читаю. Пока не вижу разницы:

Например,

nix-env --uninstall firefox && nix-collect-garbage

emerge -C firefox && emerge -c

Реквестирую обсуждение ракетки против гуйля. Пока нашел только то, что гуйль в 5 раз тормознее. Хотелось бы услышать что-либо про языковые возможности и подводные камни. Вот про ракетку например я недавно узнал что хоть в ней и можно засунуть картинку в сырец, однако сырец с картинкой завернуть в экзешник уже не получится (девелоперы в курсе но не знают как чинить). Что по это поводу может предложить гуйль?

портаж не имеет тех возможностей, которые имеет nix

А можно поконкретнее, каких именно. И почему эти возможности так важны и без них невыносимо жить.

Для крутых разрабов всегда есть /usr/local или даже ~/local.

А дистрибутив - это платформа.

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

Всё-таки раньше тролли были изобретательнее, изящнее я бы сказал :)

будет.

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

Ты почти в любом языке можешь картинку в исходники засунуть. В base64.

его разрабатывают на функциональном языке Scheme

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

иметь 9999 версий одной либы и программы гарантировано не будут ломаться при обновлении (в портаж с @preserved-rebuild есть стремление к подобному, но оно не покрывает все возможности, напр языки с нестабильным abi, типа haskell, ruby, etc.).

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

Тоже не могу пока найти такие. Откат версий пакетов вроде бы в никсе есть, но..

nix-env --upgrade some-packages
nix-env --rollback

аналогично в портаж:

echo "some-packages-номер_ненужной_версии" >> /etc/portage/packages.mask/my-mask (говорим, что эта версия нам не нужна)
emerge -uDk some-packages (обновляем пакет и зависимости)
emerge -ac (проверяем остались ли пакеты без зависимостей и удаляем их)

Вместо emerge -uDk some-packages можно круче, но дольше: emerge -uek some-packages. Здесь гарантированно все зависимости зависимостей пересчитаются, а не только самого пакета.

Это не нужно на серверах. Но линукс на десктопах(как ubuntu) - это совсем другое дело. Мне например нужны браузеры различных версий. Если бы их можно было установить не в виртуалки, а штатно в моём дистре - я был бы очень рад. Устанавливать целый дистр на виртуалку только ради старой версии браузера - это как-то не правильно.

в Nix в названии пакета присутствует хеш-код, описывающий зависимости пакета:)

«Если бы в линуксе была реальная конкуренция (на десктопе ее точно нет), то все бы так хорошо и работало.» Странно. А почему Вы считате, что на десктопе ее нет? Если в разработке десктопных программ не участвуют крупные компании, то это еще не значит, что конкуренции нет.

«Часто забывается, что ОС не имеет никакой ценности сама по себе, главное - приложения.» Не вижу логической связи. Да, количество ядер ОС все-таки должно быть меньше, чем количество текстовых редакторов, например. Но причем здесь пакетный менеджер? Он все-таки не настолько важная часть системы, чтобы без него не работал весь остальной софт.

Вместо того, чтобы дорабатывать имеющееся, сразу бегут форкать. Что за мода такая.

софт — не физическая система, вредоносному действию хаоса не подвержен.

зачем?

Собственно, без возможности установки никакой софт работать и не будет.

# nix remove emacs ERROR: you have no permission to remove GNU/Emacs # nix install firmware-linux-nonfree ERROR: you have no permission to install non-free packages

И будет работать только на линухе, но не на *БСД и прочих осях на которые «некошерная» лицензия.

Насчет языка для разработки - рукалицо.

было бы неплохо, если разработчикам не приходилось собирать программу под over9000 дистрибутивов с их несовместимыми версиями библиотек, а следовать некоторому стандарту и делать 2-3 пакета

вдогонку:

для любых дистрибутивов GNU/Linux

вспоминается фраза с vista.nsk.ru:

В 1974 году Билл Гейтс впервые увидел персональный компьютер. Он мечтал, что совсем скоро подобный компьютер сможет купить себе каждый человек на земле, независимо от того, в каком штате он живёт.

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

Зы. я не БСДшник, но вражда к конкурентам - признак упадка.

было бы неплохо, если разработчикам не приходилось собирать программу под over9000 дистрибутивов с их несовместимыми версиями библиотек, а следовать некоторому стандарту и делать 2-3 пакета

А что, кто-то собирает под все системы?

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

Зы. я не БСДшник, но вражда к конкурентам - признак упадка.

Для того, чтобы БСД стала конкурентом, нужно сначала умереть.

есть ооочень много чего
а run и bin - это не форматы пакетов

нет, этим приходится заниматься пользователям.

Для того, чтобы БСД стала конкурентом, нужно сначала умереть.

s/нужно сначала/она должна сначала/;

Не нужен.

Спольски уже вспоминали?

Но идея унификации мешанины из программирования на Visual Basic и Windows API созданием полностью новой среды программирования не с одним, не двумя, а с тремя языками (или есть четвертый?) похожа на попытку заставить замолчать ссорящихся детей еще более громким криком «Замолчите!». Это сработает только в сериале. В реальной жизни, когда вы кричите «Замолчите!» двум громко спорящим людям, вы просто становитесь третьей стороной в споре.

(Между прочим, то же самое происходит с форматом RSS. Он разделился на несколько версий с неточными спецификациями и большим количеством политической борьбы, а попытка навести порядок созданием еще одного формата, названного Atom, привела к нескольким различным версиям RSS плюс одна версия Atom, неточным спецификациям и большим количеством политической борьбы. Когда вы пытаетесь объединить две противостоящие силы созданием третьей альтернативы, вы получите три противостоящие силы. Вы ничего реально не объединили и не исправили.)

Написано 7 лет назад.

...Но в принципе, если заработает, я буду приятно удивлён.

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

Для этого не нужно ни никса, ни портежа. Достаточно просто развести слакварь в системе.

«Собственно, без возможности установки никакой софт работать и не будет.» Странная у Вас логика, очень странная. Без обид, но Вы сравниваете горькое с квадратным.

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

Но ведь пакетный менеджер - совсем другая история. Без него вообще можно обойти, благо старый добрый «make install» еще никто не отменял. Можно один пакетный менеджер с успехом заменить на другой, аналогичной функциональности. И ничего особо не изменится.

А вот ФОРМАТЫ самих пакетов - уже другая история. Здесь уже все сложней. Тут уже действительно стоило бы уменьшить разнообразие. Хотя возможно, что ситуацию спасло бы наличие некого «суперформата». Был бы разработан какой-нибудь специальный формат, который был бы специально предназначен для того, чтобы из него автоматически гененировались корректные rpm, deb, ebuild и т.д.

Откат версий пакетов вроде бы в никсе есть, но..

С деревом в git можно откатиться вообще куда угодно, главное тарболы с исходниками отыскать. :)

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

Положи их в /opt/firefox-14 /opt/firefox-15 /opt/firefox-16 /opt/firefox-17 и т.д. Остальные аналогично. Кто запрещает?

Но самая главная особенность GNU Guix заключается в том, что его разрабатывают на функциональном языке Scheme.

...ну а то, какая там используется идея с зависимостями — эт так фигня, по сравнению с Scheme :-D

как в бзде, юзеру в хомяк.

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

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

специальный формат, который был бы специально предназначен для того, чтобы из него автоматически гененировались корректные rpm, deb, ebuild и т.д.

man alien

работать только на линухе, но не на *БСД

Зачем тревожить мёртвых?

эх, если бы это случилось лет 10-15 назад...

«Советую вспомнить законы биологии: чем больше разнообразие видов, тем устойчивей экосистема.»

Тем быстрее произойдет перенаселение и новое вымирание видов.