Comments 17
Есть ли какие-то явные преимущества в сравнении с Raspbian?
Кроме KISS можно еще добавить более свежие версии программ в репозитории. Чем дольше имеешь дело с Raspbian тем больше это начинает напрягать.
У Arch базовая установка более компактная, меньше запущенных сервисов. Но в администрировании Arch конечно более трудозатратный.
У Arch базовая установка более компактная, меньше запущенных сервисов. Но в администрировании Arch конечно более трудозатратный.
В администрировании Arch ничем не отличается от любого другого linux IMHO.
Не отличается ровно до первого обновления, ломающего что-нибудь важное, и требующего выполнения странных телодвижений для починки, которые в нормальном дистрибутиве бы автоматически выполнились при установке пакета. Так что поиграться можно, а в продакшн ни-ни.
Arch больше образовательный проект (как и RPi). Идеологически он ближе к Linux From Scratch и для промышленного применения не особо подходит (как и RPi).
Не сложно использовать Arch в Production, на мой взгляд. И, как и в любой production системе, обновления должны быть проверенные и содержать только bug fix'ы.
И да, Arch требует от администратора чуть большего понимания о том что он делает, но это и есть пресловутый Arch Way. Выбирая Arch ты с этим соглашаешься или выбираешь другой linux.
И да, Arch требует от администратора чуть большего понимания о том что он делает, но это и есть пресловутый Arch Way. Выбирая Arch ты с этим соглашаешься или выбираешь другой linux.
Главным преимуществом, как мне кажется, является модель — rolling release, при которой вы всегда имеете (можете иметь) систему в актуальном состоянии. При этом не надо обновлять всю систему раз в год/пол года.
Обожаю арч и сижу на нем довольно давно, однако преимущество rolling release в случае с серьезными продакшын системами далеко не примущество, а, скорее, наоборот. Несколько раз наживал себе проблем, после чего стараюсь на критических машинах использовать что-то наподобие debian. Плачу, глядя на uname -r, выдающий 2.6.*.*, но ничего иного не остается.
Я бы еще добавил fake-hwclock в инструкцию для восстановления времени после перезапуска.
Сначала Pidora, теперь Pidarch?
>подключенный к WiFi сети, синхронизирующий время через интернет
А можно system.d заставить запускать определённую программу/служба только после того, как время будет реально синхронизованно (а не просто запущенна служба ntp), но чтобы при этом эта программа/служба имела статус «respawn» (или как оно тут зовётся), т.е. её нельзя было завершить и она перезапускалась бы при падении с ошибками?
А можно system.d заставить запускать определённую программу/служба только после того, как время будет реально синхронизованно (а не просто запущенна служба ntp), но чтобы при этом эта программа/служба имела статус «respawn» (или как оно тут зовётся), т.е. её нельзя было завершить и она перезапускалась бы при падении с ошибками?
Думаю, можно. Кроме запуска основной программы запускать принудительно синхронизацию времени. Если синхронизация завершилась с ошибкой то делать перезапуск. Подробнее здесь. Параметры ExecStart, Restart, RestartSec.
Какое время загрузки данной системы на Raspberry? Сколько секунд с момента включения питания до возможности использовать консоль?
а вы пробовали Buildroot? Говорят проще уже просто некуда, и это не дистрибутив как Arch, а custom linux. Мне интересно что проще реализовать было бы на той же распебри и что бы быстрее и надёжнее работало.
Sign up to leave a comment.
Arch Linux на Raspberry Pi