In Nix, different users can have different “views” on the set of installed applications. That is, there might be lots of applications present on the system (possibly in many different versions), but users can have a specific selection of those active — where “active” just means that it appears in a directory in the user’s PATH. Such a view on the set of installed applications is called a user environment, which is just a directory tree consisting of symlinks to the files of the active applications.
Для начала apt может быть не только фронтендом(хотя и это не совсем верно) к dpkg, к rpm его кажется в PSlinuxOS прикрутили, а aptitude(как и apt-get, Synaptic, Adept) это фронтенд к apt(библиотеке).
Еще как можно. Авторы предоставляют бинарную сборку Nix для SUSE, Fedora, а для Debian, *BSD можно собрать ручками.
Вот только что собрал в Ubuntu 8.10 без каких-либо проблем.
Что же касается пакетов, которыми будет управлять Nix, то и тут все нормально. Пакеты складываются в очень хитро названные директории, и коллизий не будет.
Прикрутили бы к линупсу порты от ФриБЗД — было бы счастье. Но красноглазики не знают что такое ФриБЗД, потому и изобретают велосипеды с квадратными колёсами.
Вы читали то, что написано в статье, только честно?
Apt хорошая штука и все такое (как и другие менеджеры), но в них нет, например, истинно атомарных обновлений и откатов (и это даже не получится сделать).
… и сломай систему. Точнее, молись на мейнтейнеров, только они в силах предотвратить неминуемое (и они обычно справляются с этим, ценой долгих часов тестирования).
Для того, кто будет заниматься сборкой пакетов, тоже не сильно болшие различия.
Если же посмотреть с другой стороны, то Nix очень твердо управляет побочными эффектами, в то время как побочные эффекты очень твердо управляют другими пакетными менеджерами.
Обещанная атомарность всё-таки вызывает большие сомнения. за счёт чего она достигается?
> вполне допускается содержать несколько версий одного пакета одновременно (например, это может пригодиться, если двум каким-то приложениям требуются две версии одной и той же библиотеки)
а вот это сильно похоже на путь MS Windows в DLL HELL (собсвенно подход тот же).
Хабр вообще не предназначен для постов с точкой зрения не совпадающей с точкой зрения большинства. Я вот недавно троллил в теме про трехмерные танчики во флеше: кроме того, что я обильно поливал быдло различными ругательствами (после того, как ко мне обратились на «ты» и послали в пень) я еще приводил ссылки и четко объяснял свою позицию. В карму насрали порядочно. habrahabr.ru/blogs/Flash_Platform/47270/#comment_1212337
В общем я к тому, что хабр предназначен для общения. Троллинг это часть сетевой культуры. Хороший провокатор в комментариях может разжечь интересную дискуссию и выявить дилетантов. «Хабр уже не тот» именно из за того, что хабралюди стремятся к пидорской толерантности.
> Хабр вообще не предназначен для постов с точкой зрения не совпадающей с точкой зрения большинства.
Я заметил уже.
> я еще приводил ссылки и четко объяснял свою позицию.
Ну так это не троллинг как таковой (у тролля обычно мнения меняются от поста к посту). По ссылке сходил, правда, в танчиках на флэше я не разбираюсь и потому ничего не буду говорить.
> В общем я к тому, что хабр предназначен для общения.
Из твоего комментария я вынес, что Хабр для троллей и любителей впустую почесать языком. Неплохое начало.
> Ну так это не троллинг как таковой (у тролля обычно мнения меняются от поста к посту).
Это у плохого тролля (в всяком случае в тематике хабра противоречивость неуместна), обычно они сами источник лулзов, скатываются до прямых оскорблений, не видят желаемой реакции и уходят и треда. А те чей троллинг ограничен унылыми постами типа «виндовс для лохов» (типа вот вам мой супер-провокационный пост) и не тролли вовсе. Хороший тролль разжигает интерес, привлекая шарящих ребят в дисскусию, что кстати очень актуально для хабра, поскольку постят они все меньше. Все дискуссии скатываются во взаимое подлавнивание на ошибках. «Извините, уважаемый, но у вас ширинка расстегнута», «Побойтесь Бога! Я просто только что из клозета и не успел ее застегнуть. А у вас, господин, между прочем, блевотина на пиджаке справа.»
> Из твоего комментария я вынес, что Хабр для троллей и любителей впустую почесать языком.
Неплохое начало.
И ребят которые шарят в теме. Просто любителей впустую почесать языком 90%, и они очень не любят, когда их называют плохими словами, или Боже упаси, не уважают их никчемное мнение и мудацкую систему ценностей.
Хочу заметить, что и этот конь не спасает от «кровавых» случаев, когда используемые в вашем проекте библиотеки зависят различные версий одного и того же API (Случай когда, А завист от B и С, В зависит от D v1.0 а C зависит от D v1.1). Такое часто встречается в модульных архитектурах с открытым SDK(несовместимость плагинов).
> тот конь не спасает от «кровавых» случаев, когда используемые в вашем проекте библиотеки зависят различные версий одного и того же API (Случай когда, А завист от B и С, В зависит от D v1.0 а C зависит от D v1.1)
В Nix может одновременно существовать несколько версий одной библиотеки, которые будут мирно сосуществовать (не мешая друг другу), так что полет нормальный.
Имхо, авторы слишком на большой кусок сразу замахнулись. Откусить-то откусили, а проглотить уже не получается. В пакетных менеджерах нужно соблюдать баланс между простотой/удобством работы непосредственно системы и простой/удобством создания пакетов. В теории всё выгядит замечательно, но на практике никто этим не пользуется, поскольку сложно/непонятно/долго/добавьте-ещё-что-по-вкусу.
Прежде чем писать такие комментарии, подготовьте аргументы (факты сойдут).
Nix на самом деле очень прост для мейнтейнера и прост для конечного пользователя.
> В теории всё выгядит замечательно, но на практике никто этим не пользуется, поскольку сложно/непонятно/долго/добавьте-ещё-что-по-вкусу.
Тут дело в инертности большинства разработчиков. Например, из-за этой же инертности мы все еще используем доисторические инструменты (toolchain, ЯПы, etc.)
Другой пример: сборщик мусора появился в Лиспе почти за 30 лет до Java (а до этого все говорили «В теории всё выгядит замечательно, но на практике никто этим не пользуется, поскольку сложно/непонятно/долго/добавьте-ещё-что-по-вкусу»).
Какие аргументы? Какие факты? Системой никто не пользуется; я когда-то читал статьи с их сайта, поскольку на работе предстояло нечто подобное сделать (подробнее не могу — NDA). В итоге оказалось, что непосредственные исполнители ТАКИМ пользоваться не хотят. И неважно, чем они это обосновывают. Просто не хотят и всё.
Подобной же судьбы удостоился semantic web, который имеет отличную теоретическую базу, однако на практике никто им не пользуется, посколько целевая аудитория не хочет строго формализовать метаданные.
Возвращаясь к Nix. С исследовательской точки зрения проект замечательный, но для его приближения к «простым пользователям» красивой теории недостаточно.
> непосредственные исполнители ТАКИМ пользоваться не хотят
Заставляйте силой. Иначе никак.
> И неважно, чем они это обосновывают
Мы вообще-то люди, и голова нам дана не только для того, чтобы есть да шапку носить. Нет обоснований — GTFO. (Это, конечно, не к Вам относится, а к заказчикам.)
> Подобной же судьбы удостоился semantic web
Неверная аналогия. Semantic web использует неправильные абстракции, только и всего. Укурки из W3C вообще уже десять лет пытаются воскресить мертвеца HTML, который уже давно не используется для собственно гипертекстовых документов.
Менеджер пакетов нужен пользователю. Он должен быть прост, понятен и надёжен, nix же — это нечто для гикоского развлечения, а не для работы.
Более того — всего, от чего он должен помогать можно добиться стандартным инструментарием POSIX-like systems ($PATH, chroot etc.), и это всё безусловно полезно [для разработчиков], а для конечного пользователя представляется ненужным/опасным (это про содержание кучи разных версий библиотечек).
Возможность отката — штука полезная, но так ли часто она необходима?
Наверное вы не встречались с такими проблемами. Поблема в том, что в рамках одного процесса требуется загрузить в память сразу 2 версии одной и той же библиотеки. Без «магии» загрузчиков этого увы никак не сделать.
От этого спасает правильное именование библиотеки и последующая правильная линковка. Если разработчики не совсем дураки, то при установке библиотек и измения ABI они делают разные имена. Это позволяет загружать эти библиотеки вместе.
Идеи, заложенные в основу Nix — очень правильные. Похожий механизм мы используем у себя для автоматической сборки J2ME-билдов — это порядка 20 различных конфигураций на один проект.
Если бы не свой «велосипед» сборка всех билдов занимала бы 30 минут, а так на сборку первого билда уходит 1.5 минуты, а на все последующие по 10-20 секунд(в зависисмости от степени различия).
Холивар начался незаметно =)
А если серьезно, то NIX получит широчайшее распространение только если сделает себя совместимым с репозиториями других типов (bsd ports, debian, etc). В противном случае имеем не эволюцию, а революцию, которые, как мы знаем, весьма кровопролитны.
Неправда. apt-get и apt-cache тормозит почти точно также как и Synaptic, при вызове он что-то там делает с базой (то ли переиндексирует, то ли еще что-то, но какая-та длительная операция проводится, а про кеширование видимо авторы не слышали). Поскольку инициализация идет секунд 10-15, а за это время можно прочесть с диска порядка 100-300 Мб, можно сделать вывод что что-то там неэффективно сделано. Доходит до такой глупости, что скачивание небольшого пакета и его распаковка происходят быстрее чем сама инициализация apt. По крайней мере у меня притормаживает, подозреваю это зависит от кол-ва паекетов в базе.
> Nix позволяет непривилегированным пользователям устанавливать ПО.
Вот это уже интереснее)) Хотя наверно найдутся и желающиее отключит эту опцию.
Я правильно понимаю, что в Nix как и в www.gobolinux.org/ для одного пакета — одна папка, тогда для совместимости надо делать симлинки в стандартные папки никсов: /bin, /usr/bin… итд? Иначе полавина софта и скриптов без изменения просто не сможет работать. Я не очень понял как там можно поставить 2 версии библиотеки и разным приложениям сказать чтобы они использовали какуе-то из них.
> тогда для совместимости надо делать симлинки в стандартные папки никсов: /bin, /usr/bin… итд?
Нет, неправильно понимаешь. Nix делает эти ссылки в своей директории (либо в директории пользователя), а тебе нужно прописать одну из этих директорий в PATH.
> Я не очень понял как там можно поставить 2 версии библиотеки и разным приложениям сказать чтобы они использовали какуе-то из них.
В общем, достаточно будет сказать, что оно работает — как именно это работает, смотри в документации.
Nix — менеджер пакетов следующего поколения