Кто-нибудь использует NixOS?

Впервые слышу

такая ж хрень.

А вообще похоже на скрытую рекламу.

Ле, пожтому на ЛОРеесть новости про него. По сабжу стоит накостовать боржевиков разных мастей. Стас Михайлов, вроде, говорил, что он умер.

Но зачем? Оно интересно выглядит в теории, но на практике — нафиг.

Docker и тот интереснее с CoreOS. Пакетные менеджеры не нужны.

Пакетные менеджеры не нужны.

И почему же?

Потому, что они решают не слишком актуальную проблему (минимум места на диске), которая обходится включением всех зависимостей в пакет. И проблема «нужно 2 разные несовместимые версии библиотеки двум разным пакетам» решается слишком сложно. Нафиг.

а обновления безопасности кто будет собирать?

Насколько я понимаю, проблему разных библиотек в NixOS решили: при обновлении старые версии не удаляются (можно делать nix-rebuild test, switch, boot (думаю, понятно, что они делают из названия)), но потом можно сделать «garbage collection».

По поводу docker'а: разве это не для виртуальных машин?

а обновления безопасности кто будет собирать?

Кто сказал, что они должны быть опакечены в терминах нынешних пакетных менеджеров? Бинарный дифф к образу системы и всё.

и кто будет сотни человеко-лет просирать на это неблагодарное дело? :)

Эмм. Что?

Если девелопер может собрать бинарники, то нет никаких технических проблем запустить эти бинарники где угодно. Получить нужное окружение на юзерских компьютерах — давно решённая задача (одно из последних решений — контейнеры с CoreOS). Сделать бинарный дифф между текущим и предыдущим билдом — опять же задача компьютера, а не человека.

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

Если девелопер может собрать бинарники

Значит, каждый девелопер каждой мелкой программы должен сам вместо мейнтейнеров собирать всякие Qt, Gtk, их зависимости, зависимости зависимостей, обновлять их по мере выхода новых версий и обнаружения уязвимостей? )

Значит, каждый девелопер каждой мелкой программы должен сам вместо мейнтейнеров собирать всякие Qt, Gtk, их зависимости, зависимости зависимостей, обновлять их по мере выхода новых версий и обнаружения уязвимостей? )

Нет, каждый девелопер должен установить нужную зависимость (одну) вроде "runtime:org.gnome.GNOME3_20:x86_64:3.20.1". Всё. Уязвимость у него — фиксит свой софт, нет — рантайм за него пофиксят.

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

А в команде дистрибутива вместо ментейнеров будут нужны только 2 команды: аппрувер, чтобы троянов в репозитории не было и security-команда, способная быстро выпустить фикс к чему-то вроде shellshock до того, как апстрим отреагирует.

Тысячи зависимостей и тысячи мелких пакетов в базовой системе — legacy и должны умереть. Если они останутся у ментейнеров рантаймов — ок, но конечному юзеру это нафиг не нужно. Именно dependency-hell обеспечивает дублирование работы в каждом дистрибутиве без каких-либо преимуществ.

Да, тоже об этом подумал

т.е. мейнтейнеры у этого дистра таки есть?

Вызываю perestoronin.

Преимущество пакетных менеджеров (для меня) в том, что они позволяют без геморроя (а у меня никогда не было конфликтов версий на арче, кроме проприетарных драйверов от AMD и новых иксов, что в конечном итоге вылечилось переходом на свободные) устанавливать, удалять и обновлять пакеты одной командой, а не жать каждый раз «обновить Firefox».

По поводу dependency hell'а: не очень понятно, что мешает хранить все версии библиотек и других пакетов, которые есть в зависимостях других пакетов. Например: иметь в системе не /lib/libsuper.so, а /lib/libsuper.so/{versions}/libsuper.so и дёргать их в зависимости от софта. В моём представлении это должно решаться с помощью «пространств имен»: каждый процесс/программа имеет список требуемых библиотек, запрашиваемых устройств, прав доступа и т.д., а уже специальный менеджер будет подсовывать им нужные ссылки на файлы. Возможно, так уже где-то и реализовано, но я не знаю - если скажете, то буду премного благодарен.

Возможно, это не реализуемо в рамках ядра linux, но может есть альтернативы?

Потому, что они решают не слишком актуальную проблему (минимум места на диске)

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

Они решают проблему обновления зависимостей без переустановки самого пакета.

Эта проблема спокойно решается без пакетов в таком виде.

Если разработчик запаковал в архив библиотеку версии 2, а я хочу версию 3 и знаю что они совместима

Разработчик должен знать, что она совместима, а не ты. Кстати, перечисли последовательность действий, чтобы собрать свою программу с каждой поддерживаемой версией библиотеки в каждом мажорном дистрибутиве и прогнать все свои тесты с этой конфигурацией — поймёшь, что не так с системой пакетов.

Но без системы пакетов же ещё хуже! Это если делать всё руками, а если начать этот процесс автоматизировать, то появляется система пакетов... Возможно, в другом виде.

Эта проблема спокойно решается без пакетов в таком виде.

В каком «таком»?

Разработчик должен знать, что она совместима, а не ты.

Ну вот посмотри на ведроид. Мы имеем пакеты с багами библиотек, потому что разработчик не потрудился библиотеки обновить или вообще пропал/умер.

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

Кстати, перечисли последовательность действий, чтобы собрать свою программу с каждой поддерживаемой версией библиотеки в каждом мажорном дистрибутиве и прогнать все свои тесты с этой конфигурацией — поймёшь, что не так с системой пакетов.

у того же Qt разных библиотек в зависимостях больше, чем «мажорных дистрибутивов»

И сборка пакетов под разные дистры относительно легко автоматизируется

http://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.html в светлом будущем и костыли с деплоингом своих приложений в тёмном настоящем (о десктопах в настоящем никто не думает).

Проблема не с пакетами как с концепцией, а с нынешней экосистемой линуксовых пакетов как с конкретной legacy-реализацией этой идеи.

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

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

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

разработчик не обязан следить за всеми зависимостями и тестировать их на совместимость

Я делаю мелкую программу для узкой группы людей. У неё нет шансов попасть в основные репозитории. Мне просто выложить исходники и тесты и молиться Харухи, что юзеры осилят сборку?

См. ссылку выше на один из вариантов настоящего решения проблемы.

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

Когда я хочу поставить одно десктопное приложение, мне не хочется учитывать, что от чего зависит, с чем конфликтует, о чём стоит делать багрепорт ментейнерам, а о чём в апстрим. Ну и не слишком хочется ждать ебилдов/пакетов, которые появляются позже релиза в апстриме (апстрим не может следить за всеми дистрибутивами и его ресурсы небесконечны). А сейчас один объём документации к одному apt больше, чем Война и Мир и это без учёта особенностей одного дебиана, не говоря о других дистрибутивах. Начерта так усложнять? Это — классическое complex non-solution to a simple non-problem.

Ну вот посмотри на ведроид.

Посмотри на объём плей-маркета. Там 0 ментейнеров.

разработчик не потрудился библиотеки обновить или вообще пропал/умер

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

Поттеринг пусть идёт в жопу со своей версией светлого будущего

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

Ты будешь отрицать нужность тестов?

У неё нет шансов попасть в основные репозитории. Мне просто выложить исходники и тесты и молиться Харухи, что юзеры осилят сборку?

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

Да, это — сильный аргумент. Из разряда ad hominem. За такое в приличном обществе посылают в известном направлении как демагога, а в менее приличном — дают в морду.

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

Ну что теперь делать, this software is provided AS IS, with ABSOLUTELY NO WARRANTY :)

Если у юзера какое-то своё странное окружение, он может заплатить за решение своих персональных проблем

Репозиторий для какого дистрибутива? Туда складывать вообще всё дерево зависимостей выше glibc? Стараясь не пересечься с дистрибутивными версиями?

Честно говоря, тарболл со всеми зависимостями — более разумное решение.

Ничего, что эта проблема создана и поддерживается на ровном месте? Иногда возникает такое чувство, что это — одна из составляющих бизнес-модели опенсорс-сообщества.

Туда складывать вообще всё дерево зависимостей выше glibc? Стараясь не пересечься с дистрибутивными версиями?

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

Ничего, что эта проблема создана и поддерживается на ровном месте? Иногда возникает такое чувство, что это — одна из составляющих бизнес-модели опенсорс-сообщества.

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

И следить за дистрибутивом (каким?), обновляя репозиторий. Замечательно.

Знаешь, под *все* прочие ОС делать приложения гораздо проще. Девелоперы могут сравнивать. А потом возникают вопросы вроде «почему 1%».

Объясни, почему работа ментейнера нужна только в GNU/линуксе. Это — настолько уникальная ОС, что в ней обязательно должны присутствовать ментейнеры? Новое слово в computer science?

Знаешь, под *все* прочие ОС делать приложения гораздо проще. Девелоперы могут сравнивать.

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

Объясни, почему работа ментейнера нужна только в GNU/линуксе.

Она везде нужна в том или ином виде

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

Под винду число зависимостей вообще *всех* приложений можно посчитать на пальцах: это версии MSVCRT, .NET и DirectX (последнее — малоактуально сейчас). А руками их трогать — не приходится при вменяемых девелоперах, сделавших нормальный пакет (сюрприз! там тоже есть пакеты (причём с тонной странных/плохих решений), но нет ада зависимостей). Под линуксом же — такое чувство, что для установки программы, для которой у ментейнеров нехватило рук, нужно чуть ли не доказать, что P≠NP. Настолько сложная система — просто не нужна.

это версии MSVCRT, .NET и DirectX (последнее — малоактуально сейчас).

Это если софт вендоспецифичный и непортируемый

Для кроссплатформенного софта под линукс/мак/винду последние две - страх и ужас

Ага, так вот откуда травмы с разруливанием зависимостей руками: оказывается, виноваты девелоперы кроссплатформенного софта (а чаще — просто портированного с линуксов). Ничего удивительного.

К сведению: те же firefox/chrome кроссплатформенны, но с их установкой в windows проблем нет. Может, проблема с «зависимостями руками» — не в оффтопике?

К сведению: те же firefox/chrome кроссплатформенны, но с их установкой в windows проблем нет. Может, проблема с «зависимостями руками» — не в оффтопике?

потому что ЕМНИП там все зависимости запихнуты в дерево исходников, и кому-то основательно пришлось с этим поипстись

а вот если бы на маке и в винде был бы пакетный менеджер, как в линуксе, это всё было бы не нужно :)

https://chocolatey.org/ получите, распишитесь. Он лучше, чем в линуксе хотя бы тем, что нет тысячи зависимостей.

Прикольная штука, но оно не содержит библиотек, как я вижу, только конечные пользовательские приложения.

Кто сказал, что они должны быть опакечены в терминах нынешних пакетных менеджеров? Бинарный дифф к образу системы и всё.

Ну так всё, что при работе компьютера происходит можно описать как "бинарный дифф к образу системы и всё". Но раз уж у тебя сегодня NIH, то попробуй предложить формат упаковки и распространения этого "диффа", и объяснить, почему у тебя получился дельта-rpm, но только без тестов.

Я делаю мелкую программу для узкой группы людей. У неё нет шансов попасть в основные репозитории. Мне просто выложить исходники и тесты и молиться Харухи, что юзеры осилят сборку?

пишишь ебилд, и всё работает.

:) использую и что ? преимуществ одно - ФП в оснастке но сделано, как и любое сложное ПО очень отвратительно, но при желании все равно разобраться не сложно вроде бы живет себе проект бодрячком

а в чем суть запроса ?