Arch без systemd.

Я тоскую по настройке rc.conf и прочих конфигов.

Вся суть!

Я тоскую по настройке rc.conf и прочих конфигов.

А systemd через libtelepathy настраивается? :)

Выпили systemd.

Что-то не работает?

Уточню немного, интересует наличие AIF.

libtelepathy в ауре есть,но старый. libastral поновее будет.

дистрибутив,основанный на арче и имеющий старую систему иннициализации

LSD Linux же.

Хотя в оригинальном арче systemd точно также можно спокойно заменить на initscripts-fork + eudev-git + все *-nosystemd и *-consolekit из AUR.

Возьми себе rc.conf и настрой его. Потом можешь удалить файлик и продолжать пользоваться Арчем с нормальной системой инициализации.

Зачем использовать подделки, если есть оригинал — CRUX.

Потом можешь удалить файлик

Зачем? Нормальная система инициализации не сможет корректно работать без него.

С каких пор Systemd требует rc.conf?

Ты вроде про нормальную систему инициализации писал, а не про systemd.

нормальная система инициализции = systemd.

4.2

Спасибо, посмеялся. :)

И опять начнется кудах-тах-тах.

Стандартизированный сценарии запуска - это конечно здорово. Но зачем пихать в init систему все подряд, переходить на бинарные форматы, всасывать в себя udev9обрекая другие дистрибутивы на его форк)...еще говорят там говнокод лютый.

1.) Собери без http сервера и qt-кодов.

2.) А зачем его форкать, если можно использовать systemd?

3.) Это дело разработчиков. А сам он работает быстро.

Если твой альтернативный арч с initscripts и барышнями так хорош, то почему же ты так недоволен systemd? Разве тебе наоборот, не приятно осознавать свою уникальность, ты ведь идеш против системы и все такое?

ты сам то читал ту хрень, которую запостил?

Читал, мдаа :)

Системд не нормален,он ужасен аки реестр.

Спасибо,кажись это оно. Ушёл в гугл.

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

Извини за такой вопрос... А оно работает?

Я тоскую по настройке rc.conf и прочих конфигов.

Лучше займись делом.

эти свои велосипеды недопилены, и работают плохо, хуже стандартных

Ну так используй стандартные, а встроенные не используй

100 лет уже споры про бинарные логи. Вся прелесть бинарных логов в том, что их нельзя подкорректировать и убрать «следы преступления». А смотрятся они почти как через less, ЕМНИП.

Gentoo /thread

Увы, такой фичи не предусмотрено.

systemd - лучшая система инициализации на данный момент.

А смысл в небинарных логах? Их же только парсят на предмет всякой инфы, вдобавок, обычные логи легко подправляются злоумышленниками :)

на большом компе, без наложения требований - да. Но не во всех случаях, в которых работает sysvinit, upstart, прочее. Систему легче сделать незагружаемой сторонними пакетами, но в случае своего дистрибутива это терпимо, хотя и досадно.

На мелких первым раздражающим фактором является journald, который легко уносит систему с небольшим количеством памяти в OOM killer. Причем это by design. Тривиально не чинится. Отказаться совсем от journald нельзя, так как syslog при использовании systemd работает через него. Оно просто постоянно поджирает tmpfs, даже если выключено хранение логов. Причем это не утечка памяти. Пришлось усиленно патчить systemd грязно выпиливая из него journald и впиливая обратно простой syslog. Опредленными жертвами, к сожалению. Добиться помощи от товарищей-разработчиков не удалось, поэтому есть только пропатченная древняя версия, на которой мы сейчас и сидим. Переходить обратно на sysvinit или upstart слишком дорого, А допиливать современный systemd - слишком накладно.

То есть гибкости в systemd совершенно нет, просто значительное количество пользователей прочих инитов не входит в их ЦУ, и они от линии партии в угоду этим пользователям отступать не собираются. Мне кажется, что они теряют больше, чем приобретают, так как очевидных преимуществ у systemd по сравнению с другими init'ами нет. А есть куча новых особенностей, которые в общем являются скорее препятствиями к интеграции systemd в текущие проекты, чем положительными характеристиками. systemd может похвастяться только скоростью загрузки, но это нужно достаточно незначительному количеству пользователей. Синхронизация запуска приложений работает недостаточно надежно, в результате приходится изобретать те же подпорки, что были бы использованы при systemv-init'е, так что простота и понятность системы запуска тут такая же, если не хуже, потому что часто бывают неочевидные глюки загрузки, которые приходится долго отлаживать.

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

В новых проектах следует понимать, что не нужно верить рекламе. При проектировании работы всей системы следует сразу построить все этапы загрузки, причем каждый запускаемый процесс желательно изолировать от загрузки. Никогда насильно не определять порядок. Никогда не использовать Requires. Есть удобные фичи, связанные с интеграцией udev, типа загрузки после появления устройства, но следует проверять, что эта фича работает с вашим конкретным устройством. Никогда не следует рассчитывать на автозапуск сервисов D-Bus с сипользованием systemd - используйте правильно шину, и такое вспоможение вам не потребуется, systemd с этим справится хуже и вы умаетесь отлаживать возникающие проблемы, нюансов много, перечислять можно долго.

Выпили systemd, всё отлично и без него работает, спасибо initsripts-fork и иже с ними.

И совсем другое дело, что системд малоинформативен. Это огорчает :(

Как-то расходится с собственным опытом

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

Тот же wtmp уже давным-давно научились корректировать.

Ну удачи вам, тогда.

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

Я как бы об этом и сказал, да.

Но срачи про бинарные логи как-то не утихают. Хотя я пробовал - мне ок.

Удалённые логи - первый сигнал, что что-то не так. А когда смотришь логи и не видишь ничего подозрительного - ломаный сервак долго может стоять.

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

Когда логов много, и потерянный лог часто переключает внимание на тебя, причем с возможностью лишиться части денег - не ок. Причем не ок, когда он есть, но его на самом деле нет.

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

Мне кажется, насчет логоведения в этот системдэ еще добавят опцию для экспортирования лога в текстовом формате, или что-то в этом роде.

Да уж, посмотрел я их сайт. Из последних новостей, они выпилили Python 3, и переименовали python2-* пакеты в python-. Суровый такой ролинг получается... Очередная мертворожденная поделка, короче.

дык обычно можно journalctl | grep ... или в файл. Основная проблема - добиться, чтобы в логах было то, что нужно, и даже после нажатия ресета на плате. Что имеем - не храним. rsyslogd - просто няшка по сравнению с journald... Ну и когда лог хотя бы чуть покоррапчен - journalctl, а за ним и journald - коры дампят. После этого, познавши секс чтения логов этого чуда, больше этого никогда в жизни делать не хочется, и начинаются поиски способов это дело выпилить. Потому, что вся идея бинарных логов, предназначенных для людей, глупа сама по себе. Нам такого не надо, нам надо чтобы всё и сразу.

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

Неужели с этим не сталкивались в RH и Fedora ? Интересненько, как же они выкручивались...