LINUX.ORG.RU

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

Вся суть!

vurdalak ★★★★★ ()

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

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

Ttt ☆☆☆☆☆ ()

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

LSD Linux же.

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

AX ★★★★★ ()

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

KendovNorok ()

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

slapin ★★★★★ ()

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

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

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

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

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

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

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

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

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

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

на большом компе, без наложения требований - да. Но не во всех случаях, в которых работает 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 с этим справится хуже и вы умаетесь отлаживать возникающие проблемы, нюансов много, перечислять можно долго.

slapin ★★★★★ ()

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

RedEyedMan3 ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.