>> Перезапуск одного повисшего процесса не должен происходить перезапуском всей системы
> А вот это - зависит от. С чего это вы за всех
> решили что так - нельзя? Вон у фирмы Нокия, например, у
> продакшн версий смартов N9 и N9x0 - отвал критичного сервиса ведет
> к ребуту девайса (разработчики - могут сие отключить).Почему нельзя просто перезапустить сервис, ведь это гораздо быстрее?
>> Я сам - нет, мне это не нужно. Но если кто пришлет
>> нормальный патч и поддержка будет опцией - почему нет?
> Если вам свалится в ваш проект ассемблерная простыня на 100 килобайтов, в
> которой вы ни в зуб ногой - врядли вы ее станете
> сами саппортить, just in case. А половина програмеров решит что это
> тянет на совсем отдельный проект. Не всем же пхать в свои
> репы любой мусор, как апачевский могильник. Это засоряет код и/или репы.
Естественно, словосочетание "нормальный патч" подразумевает, что он будет соответствовать общему подходу проекта, включая форматирование кода. Это обычные требования практически всех открытых проектов.
> В менуэт оси все пишется на асме. Идея фикс у них такая.
Так у себя пускай на нем и пишут.
>> Речь не о том, что бы писать все самому. А о том
>> что бы иметь много простых решений для каждой задачи.
> Все хорошо в меру. Вот сисколы управления процессами например - то еще
> лоскутное одеяло. При том привилегированное и чувствительное к порядку вызова.
> С административной точки зрения, иметь дело с 20 простых, но совсем разных
> утилит от разных людей - утомительно.
Перечислите все 20. А то кроме iptables и стандартных команд типа mount ничего в голову не приходит.
> А из-за природы явления -
> граблебагоопасно и требует от админа глубокого знания устройства системы и работы
> всех 20 утилит. Прописать 20 параметров в единообразном виде в 1
> конфиг - проще. И меньше места для лажи. А фанаты sysv
> обычно просто кладут на половину подобных вещей. Не обрабатывая ошибки и
> сбои и делая много фривольных допущений. А когда все нагибается и
> даже по ssh зайти не получается - ну да, так ваши
> и должны работать, наверное. Потому что геморно наруливать вызов 20 разных
> утилит. Особенно с анализом всех мыслимых ошибок в этом процессе. Вот
> только мне не нравится как все это потом работает.
А по факту, практически все ограничивается стандартными командами и их поведение более предсказуемо.
>> И использовать их по необходимости (типа unix way). А не одно навороченное переусложненное.
> Тут приводили пример к чему это приводит. Когда чтобы достать 10 файлов
> из бэкапа - надо распаковать половину архива на 100 гигов. Потому
> что tar юниксвейно запайпили в gz.
unix way запрещает взять более подходящий архиватор, если изначально задача в извлечении отдельных файлов?
>> А инит система - связующее звено для этих блоков.
> Ну то-есть вы уже тоже не считаете что инит - только запускалка,
> в стиле "fire and forget", каковой всегда был init и большинство
> его скриптов?
Запускал + перезапускалка сервисов. Остальное - задача сервисов и приложений.
>> не нyжен d-bus
> Насколько я помню, там в configure таки есть --disable-dbus. Правда на мой
> вкус это очень спорная идея. Я за то чтобы в системе
> был нормальный IPC и это не было бы чем-то сильно опциональным.
> Оборвать это? Procfs в ядре себе оборвите, больше лулзов.
Зачем? Procfs, sysfs и devtmpfs (написанная кстати Кеем Сиверсом) - отличные вещи, которые я постоянно использую. Да и все ядро жрет памяти примерно столько же, как udev+dbus.
>> udev все равно используй.
> Ему довольно мало альтернатив.
Хватает. Можете погуглить. Я лично использую mdev - ничего в памяти не висит, гибкий простой, хорошо поддается дебагу - даже не знаю чего еще хотеть.
> Ну то-есть можно нечто типа того что в
> openwrt, но, честное слово, грабель с оборудованием в openwrt много.
Это проблемы дистрибутива (его особенностей или кривых рук).
> А > юсб какой-нибудь нынче есть даже в модуле с половину кредитной карты
> размером. А значит и полный букет проблем с горячим подключением оборудования.
> Время признать очевидные факты: подобная подсистема нужна на большинстве устройств. Потому
> что там есть как минимум usb. Ваши же аргументы, а? :)
Не вы меня за человека не считаете? Естественно хотплаг у меня работает и вроде я об этом уже вам рассказывал в предыдущих дискуссиях. Притом правила на каждый девайс составлять одно удовольствие - я себе монтирование флешек сделал с предварительной проверкой fsck (патченный для полного автоматизма). Для 3g модема - настройка и авто запуск pdnsd + polipo. И другие подобные штуки.
>>> насчет применения вашей же логики? :)
>> О какой логике речь?
> О вашей. Нужно не всем -> оборвать.
Не оборвать, а сделать опцией!
>> Вот если бы fuse была обязательным элементом системы.
> Понятие об обязательном - штука растяжимая.
Простое, если не растягивать ;) Если поставленные задачи выполняются без чего либо, значит оно не нужно.
>> это приложения написанные для его DE будут требовать systemd/PA/его DE.
> А вот это уже дело программистов как писать программы. Да, вы знаете,
> если я не захочу сношаться с вопросом "а какие там сэмплрейты
> поддерживает та звуковуха, во сколько потоков и какая гадина заняла звуковуху
> эксклюзивно" - я таки поюзаю PA.
Вот в этом и проблема. Alsa для всех проблемных карты использует dmix и конвертацию частот по-умолчанию. А мало разбирающиеся люди потом клепают PA only приложения :(
А по факту почти всем приложениям приходится поддерживать не только alsa и jack, но еще и pa и oss.
>> А зачем из держать если в них нет реальной необходимости?
> Ну так не держите. И системд можете не держать. А завтра какой-нибудь
> умник procfs у себя в ядре отпилит.
> Мне что, учитывать все
> причуды всех чудаков на свете?
Нет просто избегать жесткой привязки там, где без нее можно обойтись. Это нормальная практика и вся низкоуровневая часть ее придерживается. Пример с mesa уже приводил.
>> если ты ей не пользуешься?
> Незачем. Но судя по KVM в ядре - идея запускать виртуалки народу
> пришлась вполне по вкусу.
Естественно я не против KVM и были случаи когда она меня выручала. Речь только о том, что в системе должно быть запущено только то, что необходимо для решения текущих задач.
> А так, знаете, udev и d-bus как-то совсем не светятся
> в top как такие из себя resource hogs. Даже на довольно
> старой и довольно медленной армовской платке.
Ну и смысл тратить на них память?
>> (7-8) лет за 9 секунд грузится и жрет около 20mb.
> Правда радость от этого быстро улетучится после запуска обычного браузера. Который один
> скушает на порядок больше.
Да, но ее все же будет больше, а вероятность свопа меньше.
>> Лучше память под кэш отдать, чем под тупо болтающиеся демоны.
> Это вон те пару мегов под udev? Имеет смысл только в совсем
> микроэмбедовке с openwrt. В случае же ноута - любой браузер мигом
> съест на 2 порядка больше и попросит добавки, аннулировав результат этих
> потуг. А в типовом дистре будет результативнее вышибить значок на питоне
> из трэя - сразу +30М RSS, без очевидных потерь, одним выстрелом.
Естественно, оптимизация должна быть комплексной и избавление от d-bus/udev это только ее малая часть.
А по факту - браузер palemoon (дополнительно зачищен при сборке). Ест в среднем 150-300MB + 20MB система. Естественно система 32 бита. На ноуте 2GB памяти. Ее хватает чтобы не закрывая браузер работать со звуком или графикой, не залазить при этом в своп. Софт весь свежий.
> в пору на openwrt в качестве дистра переходить. Там еще и
> coreutils заменят на busybox.
Уже, лет пять - и как вы говорите: ЧСХ без проблем работают все обычные десктоп приложения (кодинг/графика 2d+3d/работа со звуком) и даже LO дебиановской сборки.
> Если уж RAM превыше всего, тогда ps
> и top - урезанные сойдут, наверное.
Ну зачем так сурово? Busybox с конфигом под десктоп (нормальный top/ps/etc) - 387KB, нет смысла его сильнее кромсать.
> И шелл попроще - busybox
> со ВСЕМИ утилитами весит меньше одного только bash-а.
Да, но некоторые пакеты при сборке страдают башизмами. Да и виртуальная консоль в mc нормально без баша не работает. А так да - инит скрипты на простом шеле.
