LINUX.ORG.RU
ФорумTalks

Откуда столько пиара Nix?

 ,


0

2

В послендее время, куда не полезу (youtube, reddit и т.д.), везде лезут рекомендации с обсуждениями nix (shell, os, home manager). Но ведь этой системе уже сто лет в обед. Почему же пиар лезет именно сейчас, что вот я должен всё бросить и быстрее перейти на nix? Это что, типа эффекта питона, когда его популярность резко полезла вверх, потому что его стал использовать гугл? Nix тоже кто-то из гигантов начал пиарить? Может и правда, всё бросить и перейти на nix?


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

Так бывает. Приложив достаточные инженерные усилия можно двигать нерабочую идею очень-очень долго. Но потом приходится чего-то решать.

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

Можно зафиксировать базовый образ, окей

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

Внезапно, поэтому в nixpkgs ещё сделали инструмент для сборки докер образов без Dockerfile.

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

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

В этом и разница между причиной использовать инструмент (docker) и самоцелью (nixos).

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

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

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

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

lenin386 ★★★★
()
Последнее исправление: lenin386 (всего исправлений: 1)
Ответ на: комментарий от bdrbt

от синтаксиса иногда кровь капающая из глаз может замкнуть клавиатуру

У nix, как у языка, несмотря на все его недостатки, синтаксис примерно в тысячу раз лучше, чем у всего, что родили C-шные староверы

Nexmean
()
Последнее исправление: Nexmean (всего исправлений: 2)

Ни в коем случае, линукс преодолел исторический максимум в 6℅ на десктопах, это его убивает

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

Снимают, жалко, название не нашёл, там вместо актёров реальные нарки снимались, на второстепенных ролях

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

Ну не нужна тебе допустим в программе argc, а argv нужен и что ты сделаешь, придумаешь способ куда-нибудь впихнуть argc или уберешь Werror?

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

Так ведь о том и речь, что Werror может быть удобен при разработке, но мешает мейнтейнерам при сборке снаружи.

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

Тут соглашусь, пихать в релиз -Werror это просто издевательство. Я собирал yocto под определенную плату, у меня пакетов 20 давали ошибку, в общем, сперва запускаешь ./configure, в следующую стадию встраиваешь патч, чтобы вычистить werror, потом добавляешь патч в конфиг пакета и так раз 20 с разными пакетами. Не уверен, но по моему в gcc встраивают новые ворнинги, которые на старых пакетах опять дают кучу ошибок. Частая хрень со старыми пакетами, что одна переменная в разных местах и обе без extern, тут werror конечно не виноват, просто в более новом gcc подумали, что пусть это будет не ворнинг, а ошибка )))

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

и как у тебя на overlayfs будут жить несколько версий одной и той же библиотеки?

В теории, это делается двумя путями.

Вариант первый (для нормальных библиотек): libshit.so.1.0, libshit.so.1.1, libshit.so.1.2, libshit.so.2.0… и.т.д. В одной ФС, будет жить даже без overlayfs. Пример - gtk, libstdc++, Qt и многие другие.

Ну а для упоротых случаев делается 4 оверлея (по одному для каждой версии) с этой библиотекой и ничем более, и если кому-то нужна конкретная версия - он собирает стек userdata(app(libshit1.1(base))) или userdata(app(libshit2.0(base)))

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

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

no-dashi-v2 ★★★★
()
Последнее исправление: no-dashi-v2 (всего исправлений: 1)
Ответ на: комментарий от no-dashi-v2

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

Nexmean
()
Закрыто добавление комментариев для недавно зарегистрированных пользователей (со score < 50)