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

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

Это, в общем-то, одна из проблем дебиана: отвратная документация на запутанную машинерию. Настолько, что порождает городские легенды ;)

В таком случае приведите конкретную её часть, о которой ведёте речь.

Чтение манов вслух - $500 в час.

надёжная работа менеджера пакетов?

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

И то, что все привыкли или подпёрли её костылями, не делает её не-проблемой.

Это надо в золотую рамочку, как девиз дебиана, лол.

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

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

Итак, по пунктам:

console-setup, пишущий в /etc?

Это локальное барахло от дебиана, по непонятной причине всё еще не выброшенное, когда есть стандартизированное решение от systemd. То есть, если в дебиане для чего-то есть свой исторический костыль, скорее всего будет использоваться именно он. Потому что «стабильность». Вариант от systemd даже не запакован в какой-нибудь опциональный пакет. Еще раз, кратко: обилие локальных решений перед стандартными.

Часть пакетов всё ещё поставляется с init-скриптами? А они вам мешают? Юниты systemd-то тоже идут в комплекте

А вот и не идут. Неоднократно с этим сталкивался. Кажется, в rngd как раз и нет юнита, только скрипт. Это вскрывает другую проблему: отсутствие единообразия при построении дистрибутива. Отсутствие юнита приводит к тому, что тебе придется писать юнит самому, если ты захочешь сделать какой-то оверрайд, а скрипт этого не предусматривает. Каждая часть будет иметь какие-то свои странные решения, потому что мейнтейнеру что-то там в голову взбрело. Это напрямую связано со следующей проблемой:

Про rng-tools — это вообще какая-то частный глубоко специфический вопрос.

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

Поэтому, кстати, софт в дебиане медленно обновляется: у него гигантский оверхед на сопровождение.

Доступно? По-моему, вполне.

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

И не надо. В арче кросс-компиляция тоже прекрасно работает. Вон, целый Arch Linux ARM собрали.

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

Это, в общем-то, одна из проблем дебиана: отвратная документация на запутанную машинерию. Настолько, что пораждает городские легенды ;)

В таком случае приведите конкретную её часть, о которой ведёте речь.

Чтение манов вслух - $500 в час.

надёжная работа менеджера пакетов?

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

И то, что все привыкли или подпёрли её костылями, не делает её не-проблемой.

Это надо в золотую рамочку, как девиз дебиана, лол.

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

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

Итак, по пунктам:

console-setup, пишущий в /etc?

Это локальное барахло от дебиана, по непонятной причине всё еще не выброшенное, когда есть стандартизированное решение от systemd. То есть, если в дебиане для чего-то есть свой исторический костыль, скорее всего будет использоваться именно он. Потому что «стабильность». Вариант от systemd даже не запакован в какой-нибудь опциональный пакет. Еще раз, кратко: обилие локальных решений перед стандартными.

Часть пакетов всё ещё поставляется с init-скриптами? А они вам мешают? Юниты systemd-то тоже идут в комплекте

А вот и не идут. Неоднократно с этим сталкивался. Кажется, в rngd как раз и нет юнита, только скрипт. Это вскрывает другую проблему: отсутствие единообразия при построении дистрибутива. Отсутствие юнита приводит к тому, что тебе придется писать юнит самому, если ты захочешь сделать какой-то оверрайд, а скрипт этого не предусматривает. Каждая часть будет иметь какие-то свои странные решения, потому что мейнтейнеру что-то там в голову взбрело. Это напрямую связано со следующей проблемой:

Про rng-tools — это вообще какая-то частный глубоко специфический вопрос.

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

Поэтому, кстати, софт в дебиане медленно обновляется: у него гигантский оверхед на сопровождение.

Доступно? По-моему, вполне.

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

И не надо. В арче кросс-компиляция тоже прекрасно работает. Вон, целый Arch Linux ARM собрали.

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

Так это проблема дебиана, что работа всего этого барахла либо не описана, либо описана в каких-то дремучих дебрях, потому что я действительно потратил несколько дней, и каждый встреченный мной комментарий на этот счет повторял, что в дебиане просто так принято. Это, в общем-то, одна из проблем дебиана: отвратная документация на запутанную машинерию. Настолько, что пораждает городские легенды ;)

В таком случае приведите конкретную её часть, о которой ведёте речь.

Чтение манов вслух - $500 в час.

надёжная работа менеджера пакетов?

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

И то, что все привыкли или подпёрли её костылями, не делает её не-проблемой.

Это надо в золотую рамочку, как девиз дебиана, лол.

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

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

Итак, по пунктам:

console-setup, пишущий в /etc?

Это локальное барахло от дебиана, по непонятной причине всё еще не выброшенное, когда есть стандартизированное решение от systemd. То есть, если в дебиане для чего-то есть свой исторический костыль, скорее всего будет использоваться именно он. Потому что «стабильность». Вариант от systemd даже не запакован в какой-нибудь опциональный пакет. Еще раз, кратко: обилие локальных решений перед стандартными.

Часть пакетов всё ещё поставляется с init-скриптами? А они вам мешают? Юниты systemd-то тоже идут в комплекте

А вот и не идут. Неоднократно с этим сталкивался. Кажется, в rngd как раз и нет юнита, только скрипт. Это вскрывает другую проблему: отсутствие единообразия при построении дистрибутива. Отсутствие юнита приводит к тому, что тебе придется писать юнит самому, если ты захочешь сделать какой-то оверрайд, а скрипт этого не предусматривает. Каждая часть будет иметь какие-то свои странные решения, потому что мейнтейнеру что-то там в голову взбрело. Это напрямую связано со следующей проблемой:

Про rng-tools — это вообще какая-то частный глубоко специфический вопрос.

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

Поэтому, кстати, софт в дебиане медленно обновляется: у него гигантский оверхед на сопровождение.

Доступно? По-моему, вполне.

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

И не надо. В арче кросс-компиляция тоже прекрасно работает. Вон, целый Arch Linux ARM собрали.