LINUX.ORG.RU

История изменений

Исправление intelfx, (текущая версия) :

Временно забудем, что версионирование либ в линуксе уже немного адекватно

предположим, что совместимость с shared library почему-то ломается даже в пределах одной мажорной версии

Разумеется. Вся эта кавалькада костылей начиная с докера, равно как и любые средства управления окружениями (типа языкоспецифичных pip, cabal, cargo и универсального Nix) и вообще современная Церковь Свидетелей Воспроизводимой Сборки основываются именно на этом предположении, т. к. без оного вообще нахер не нужны. :)

Если пользоваться версионированием правильно, ценность концепции воспроизводимой сборки становится равна нулю, т. к. справится любой ПМ, который поддерживает одновременную установку нескольких (мажорных) версий одного пакета (т. е. любой кроме pacman, лол) без файловых конфликтов.

Cмена версии библиотеки вызовет (вместо молитв богам совместимости) радостную, массовую и безотлагательную пересборку/тестирование всех ее [обратных? — intelfx] зависимостей

Но что это, если не pinning? Что, если я накладываю патч с исправлением на glibc для экзотической архитектуры? Или, например, собираю бинарный пакет с проприетарщиной под Nix (при этом я грамотный проприетарщик, линкую всё динамически и хочу обеспечить пользователям возможность обновлять зависимости даже после смерти продукта)? Или, например, если я оказался в ситуации, где пропускной способности хватит ровно на то, чтобы выкачать 10 КиБ бинарного патча на конкретную библиотеку?

Динамические библиотеки были придуманы for a reason.

Так что и к словосочетанию «это необходимость бандлить» есть претензия - возможность потребовать старую, конкретную или экзотически собранную версию библиотеки в Nix есть, но это - исключение, а не правило, так обычно не делают.

Бандлинг входит в само определение Nix. Если я устанавливаю пакет, то я по определению устанавливаю вместе с ним конкретно те зависимости, с которыми он был собран. Это и называется бандлинг.

В этом смысле это полная противоположность DLL Hell, так как выражение «в системе попадется DLL чуть не той версии» теряет смысл вместе со словами «DLL в системе».

Ты ещё скажи, что DLL hell в Nix невозможен, т. к. в Linux нет DLL. :)

Напомню исходный тезис, на который я ответил, что он и есть суть Nix:

DLL Hell - это необходимость бандлить по копии DLL с каждым приложением, потому что если в системе попадется DLL чуть не той версии, приложение не взлетит.

Вообще, здесь допущена (тобой) терминологическая ошибка. DLL hell — это у тебя второе предложение в составе сложноподчинённого. А «необходимость бандлить» — это костыль против DLL hell. Костыль, который в Nix возвели в ранг основополагающей идеи.

Ну и, самое дикое, «необходимость бандлить по копии DLL с каждым приложением», ага. Чего-чего, а «по копии» и «с каждым» - это точно не про Nix.

То, что Nix дедуплицирует всё что может дедуплицировать — это, скажем так, неасимптотическая оптимизация. Она ничего не меняет по сути. Если я по какой-то причине не могу воспользоваться костылём второго порядка под названием «бинарный кэш», то «по копии» и «с каждым» оказывается у меня на диске, в оперативной памяти(!), в кэше второго уровня(!!) и в TLB(!!!).

преступления против PM типа flatpak'ов не в счет

К слову, flatpak с его OSTree — это, как раз, единственное решение в своём роде, в котором реализована точно такая же дедупликация, что и в Nix. Можно даже сказать, что flatpak — это Nix done right(ish). Такое же говно, на самом деле, но хотя бы «такое же», а не «хуже», как Snap/AppImage (да ещё и с песочницей).

Итого: бандлинга нет

False.

копий нет

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

«с каждым» - нет

The only consolation (is a lie).

«DLL в системе» - нет

Ну, это как я уже сказал. :)

«приложение не взлетит» - нет, а так прям почти DLL Hell.

Да, это всё ради того, чтобы «„приложение не взлетит“ — нет». Починили то, что не сломаноDLL hell ценой здравого смысла.

Исправление intelfx, :

Временно забудем, что версионирование либ в линуксе уже немного адекватно

предположим, что совместимость с shared library почему-то ломается даже в пределах одной мажорной версии

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

Если пользоваться версионированием правильно, ценность концепции воспроизводимой сборки становится равна нулю, т. к. справится любой ПМ, который поддерживает одновременную установку нескольких (мажорных) версий одного пакета (т. е. любой кроме pacman, лол) без файловых конфликтов.

Cмена версии библиотеки вызовет (вместо молитв богам совместимости) радостную, массовую и безотлагательную пересборку/тестирование всех ее [обратных? — intelfx] зависимостей

Но что это, если не pinning? Что, если я накладываю патч с исправлением на glibc для экзотической архитектуры? Или, например, собираю бинарный пакет с проприетарщиной под Nix (при этом я грамотный проприетарщик, линкую всё динамически и хочу обеспечить пользователям возможность обновлять зависимости даже после смерти продукта)? Или, например, если я оказался в ситуации, где пропускной способности хватит ровно на то, чтобы выкачать 10 КиБ бинарного патча на конкретную библиотеку?

Динамические библиотеки были придуманы for a reason.

Так что и к словосочетанию «это необходимость бандлить» есть претензия - возможность потребовать старую, конкретную или экзотически собранную версию библиотеки в Nix есть, но это - исключение, а не правило, так обычно не делают.

Бандлинг входит в само определение Nix. Если я устанавливаю пакет, то я по определению устанавливаю вместе с ним конкретно те зависимости, с которыми он был собран. Это и называется бандлинг.

В этом смысле это полная противоположность DLL Hell, так как выражение «в системе попадется DLL чуть не той версии» теряет смысл вместе со словами «DLL в системе».

Ты ещё скажи, что DLL hell в Nix невозможен, т. к. в Linux нет DLL. :)

Напомню исходный тезис, на который я ответил, что он и есть суть Nix:

DLL Hell - это необходимость бандлить по копии DLL с каждым приложением, потому что если в системе попадется DLL чуть не той версии, приложение не взлетит.

Вообще, здесь допущена (тобой) терминологическая ошибка. DLL hell — это у тебя второе предложение в составе сложноподчинённого. А «необходимость бандлить» — это костыль против DLL hell. Костыль, который в Nix возвели в ранг основополагающей идеи.

Ну и, самое дикое, «необходимость бандлить по копии DLL с каждым приложением», ага. Чего-чего, а «по копии» и «с каждым» - это точно не про Nix.

То, что Nix дедуплицирует всё что может дедуплицировать — это, скажем так, неасимптотическая оптимизация. Она ничего не меняет по сути. Если я по какой-то причине не могу воспользоваться костылём второго порядка под названием «бинарный кэш», то «по копии» и «с каждым» оказывается у меня на диске, в оперативной памяти(!), в кэше второго уровня(!!) и в TLB(!!!).

преступления против PM типа flatpak'ов не в счет

К слову, flatpak с его OSTree — это, как раз, единственное решение в своём роде, в котором реализована точно такая же дедупликация, что и в Nix. Можно даже сказать, что flatpak — это Nix done right(ish). Такое же говно, на самом деле, но хотя бы «такое же», а не «хуже», как Snap/AppImage (да ещё и с песочницей).

Итого: бандлинга нет

False.

копий нет

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

«с каждым» - нет

The only consolation (is a lie).

«DLL в системе» - нет

Ну, это как я уже сказал. :)

«приложение не взлетит» - нет, а так прям почти DLL Hell.

Да, это всё ради того, чтобы «„приложение не взлетит“ — нет». Починили то, что не сломаноDLL hell ценой здравого смысла.

Исправление intelfx, :

Временно забудем, что версионирование либ в линуксе уже немного адекватно

предположим, что совместимость с shared library почему-то ломается даже в пределах одной мажорной версии

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

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

Cмена версии библиотеки вызовет (вместо молитв богам совместимости) радостную, массовую и безотлагательную пересборку/тестирование всех ее [обратных? — intelfx] зависимостей

Но что это, если не pinning? Что, если я накладываю патч с исправлением на glibc для экзотической архитектуры? Или, например, собираю бинарный пакет с проприетарщиной под Nix (при этом я грамотный проприетарщик, линкую всё динамически и хочу обеспечить пользователям возможность обновлять зависимости даже после смерти продукта)? Или, например, если я оказался в ситуации, где пропускной способности хватит ровно на то, чтобы выкачать 10 КиБ бинарного патча на конкретную библиотеку?

Динамические библиотеки были придуманы for a reason.

Так что и к словосочетанию «это необходимость бандлить» есть претензия - возможность потребовать старую, конкретную или экзотически собранную версию библиотеки в Nix есть, но это - исключение, а не правило, так обычно не делают.

Бандлинг входит в само определение Nix. Если я устанавливаю пакет, то я по определению устанавливаю вместе с ним конкретно те зависимости, с которыми он был собран. Это и называется бандлинг.

В этом смысле это полная противоположность DLL Hell, так как выражение «в системе попадется DLL чуть не той версии» теряет смысл вместе со словами «DLL в системе».

Ты ещё скажи, что DLL hell в Nix невозможен, т. к. в Linux нет DLL. :)

Напомню исходный тезис, на который я ответил, что он и есть суть Nix:

DLL Hell - это необходимость бандлить по копии DLL с каждым приложением, потому что если в системе попадется DLL чуть не той версии, приложение не взлетит.

Вообще, здесь допущена (тобой) терминологическая ошибка. DLL hell — это у тебя второе предложение в составе сложноподчинённого. А «необходимость бандлить» — это костыль против DLL hell. Костыль, который в Nix возвели в ранг основополагающей идеи.

Ну и, самое дикое, «необходимость бандлить по копии DLL с каждым приложением», ага. Чего-чего, а «по копии» и «с каждым» - это точно не про Nix.

То, что Nix дедуплицирует всё что может дедуплицировать — это, скажем так, неасимптотическая оптимизация. Она ничего не меняет по сути. Если я по какой-то причине не могу воспользоваться костылём второго порядка под названием «бинарный кэш», то «по копии» и «с каждым» оказывается у меня на диске, в оперативной памяти(!), в кэше второго уровня(!!) и в TLB(!!!).

преступления против PM типа flatpak'ов не в счет

К слову, flatpak с его OSTree — это, как раз, единственное решение в своём роде, в котором реализована точно такая же дедупликация, что и в Nix. Можно даже сказать, что flatpak — это Nix done right(ish). Такое же говно, на самом деле, но хотя бы «такое же», а не «хуже», как Snap/AppImage (да ещё и с песочницей).

Итого: бандлинга нет

False.

копий нет

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

«с каждым» - нет

The only consolation (is a lie).

«DLL в системе» - нет

Ну, это как я уже сказал. :)

«приложение не взлетит» - нет, а так прям почти DLL Hell.

Да, это всё ради того, чтобы «„приложение не взлетит“ — нет». Починили то, что не сломаноDLL hell ценой здравого смысла.

Исправление intelfx, :

Временно забудем, что версионирование либ в линуксе уже немного адекватно

предположим, что совместимость с shared library почему-то ломается даже в пределах одной мажорной версии

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

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

Cмена версии библиотеки вызовет (вместо молитв богам совместимости) радостную, массовую и безотлагательную пересборку/тестирование всех ее [обратных? — intelfx] зависимостей

Но что это, если не pinning? Что, если я накладываю патч с исправлением на glibc для экзотической архитектуры? Или, например, собираю бинарный пакет с проприетарщиной под Nix (при этом я грамотный проприетарщик, линкую всё динамически и хочу обеспечить пользователям возможность обновлять зависимости даже после смерти продукта)? Или, например, если я оказался в ситуации, где пропускной способности хватит ровно на то, чтобы выкачать 10 КиБ бинарного патча на конкретную библиотеку?

Динамические библиотеки были придуманы for a reason.

Так что и к словосочетанию «это необходимость бандлить» есть претензия - возможность потребовать старую, конкретную или экзотически собранную версию библиотеки в Nix есть, но это - исключение, а не правило, так обычно не делают.

Бандлинг входит в само определение Nix. Если я устанавливаю пакет, то я по определению устанавливаю вместе с ним конкретно те зависимости, с которыми он был собран. Это и называется бандлинг.

В этом смысле это полная противоположность DLL Hell, так как выражение «в системе попадется DLL чуть не той версии» теряет смысл вместе со словами «DLL в системе».

Ты ещё скажи, что DLL hell в Nix невозможен, т. к. в Linux нет DLL. :)

Напомню исходный тезис, на который я ответил, что он и есть суть Nix:

DLL Hell - это необходимость бандлить по копии DLL с каждым приложением, потому что если в системе попадется DLL чуть не той версии, приложение не взлетит.

Вообще, здесь допущена (тобой) терминологическая ошибка. DLL hell — это у тебя второе предложение в составе сложноподчинённого. А «необходимость бандлить» — это костыль против DLL hell. Костыль, который в Nix возвели в ранг основополагающей идеи.

Ну и, самое дикое, «необходимость бандлить по копии DLL с каждым приложением», ага. Чего-чего, а «по копии» и «с каждым» - это точно не про Nix.

То, что Nix дедуплицирует всё что может дедуплицировать — это, скажем так, неасимптотическая оптимизация. Она ничего не меняет по сути. Если я по какой-то причине не могу воспользоваться костылём второго порядка под названием «бинарный кэш», то «по копии» и «с каждым» оказывается у меня на диске, в оперативной памяти(!), в кэше второго уровня(!!) и в TLB(!!!).

преступления против PM типа flatpak'ов не в счет

К слову, flatpak с его OSTree — это, как раз, единственное решение в своём роде, в котором реализована точно такая же дедупликация, что и в Nix. Можно даже сказать, что flatpak — это Nix done right(ish). Такое же говно, на самом деле, но хотя бы «такое же», а не «хуже» (как Snap/AppImage), да ещё и с песочницей.

Итого: бандлинга нет

False.

копий нет

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

«с каждым» - нет

The only consolation (is a lie).

«DLL в системе» - нет

Ну, это как я уже сказал. :)

«приложение не взлетит» - нет, а так прям почти DLL Hell.

Да, это всё ради того, чтобы «„приложение не взлетит“ — нет». Починили то, что не сломаноDLL hell ценой здравого смысла.

Исходная версия intelfx, :

Временно забудем, что версионирование либ в линуксе уже немного адекватно

предположим, что совместимость с shared library почему-то ломается даже в пределах одной мажорной версии

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

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

Cмена версии библиотеки вызовет (вместо молитв богам совместимости) радостную, массовую и безотлагательную пересборку/тестирование всех ее [обратных? — intelfx] зависимостей

Но что это, если не pinning? Что, если я накладываю патч с исправлением на glibc для экзотической архитектуры? Или, например, собираю бинарный пакет с проприетарщиной под Nix (при этом я грамотный проприетарщик, линкую всё динамически и хочу обеспечить пользователям возможность обновлять зависимости даже после смерти продукта)? Или, например, если я оказался в ситуации, где пропускной способности хватит ровно на то, чтобы выкачать 10 КиБ бинарного патча на конкретную библиотеку?

Динамические библиотеки были придуманы for a reason.

Так что и к словосочетанию «это необходимость бандлить» есть претензия - возможность потребовать старую, конкретную или экзотически собранную версию библиотеки в Nix есть, но это - исключение, а не правило, так обычно не делают.

Бандлинг входит в само определение Nix. Если я устанавливаю пакет, то я по определению устанавливаю вместе с ним конкретно те зависимости, с которыми он был собран. Это и называется бандлинг.

В этом смысле это полная противоположность DLL Hell, так как выражение «в системе попадется DLL чуть не той версии» теряет смысл вместе со словами «DLL в системе».

Ты ещё скажи, что DLL hell в Nix невозможен, т. к. в Linux нет DLL. :)

Напомню исходный тезис, на который я ответил, что он и есть суть Nix:

DLL Hell - это необходимость бандлить по копии DLL с каждым приложением, потому что если в системе попадется DLL чуть не той версии, приложение не взлетит.

Вообще, здесь допущена (тобой) терминологическая ошибка. DLL hell — это у тебя второе предложение в составе сложноподчинённого. А «необходимость бандлить» — это костыль против DLL hell. Костыль, который в Nix возвели в ранг основополагающей идеи.

Ну и, самое дикое, «необходимость бандлить по копии DLL с каждым приложением», ага. Чего-чего, а «по копии» и «с каждым» - это точно не про Nix.

То, что Nix дедуплицирует всё что может дедуплицировать — это, скажем так, неасимптотическая оптимизация. Она ничего не меняет по сути. Если я по какой-то причине не могу воспользоваться костылём второго порядка под названием «бинарный кэш», то «по копии» и «с каждым» оказывается у меня на диске, в оперативной памяти(!), в кэше второго уровня(!!) и в TLB(!!!).

преступления против PM типа flatpak'ов не в счет

К слову, flatpak с его OSTree — это, как раз, единственное решение в своём роде, в котором реализована точно такая же дедупликация, что и в Nix. Можно даже сказать, что flatpak — это Nix done right(ish). Такое же говно, на самом деле, но хотя бы «такое же», а не «хуже» (как Snap/AppImage), да ещё и с песочницей.

Итого: бандлинга нет

False.

копий нет

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

«с каждым» - нет

The only consolation (is a lie).

«DLL в системе» - нет

Ну, это как я уже сказал. :)

«приложение не взлетит» - нет, а так прям почти DLL Hell.

Да, это всё ради того, чтобы «„приложение не взлетит“ — нет».