> Почему нельзя просто перезапустить сервис, ведь это гораздо быстрее?В общем случае, ребут - предсказуемее. Такие системы создают в виде когда они при включении безусловно выходят на режим, а риск развала системы при ребутах, даже внеплановых и power loss - минимизируется. Fsck на телефоне? Не катит. И мало ли где еще внутренний state развалился. Знаете, погано если телефон пропустит 5 важных звонков, будучи полдня в ауте (и у менее сообразительных вендоров такое бывает).
> Это обычные требования практически всех открытых проектов.
Тем не менее, это дополнительная сущность.
> Так у себя пускай на нем и пишут.
Так они это и делают. А если к вам припрется юзерь этой штуки и с нахрапом потребует переписать вашу прогу вот так - ваш оптимизм это делать предсказуем. Ну вот и остальные програмеры и прочие майнтайнеры при виде "вы мне тут все должны" тоже могут фак из кармана вынуть.
> ничего в голову не приходит.
Слабая фантазия!.
- Что насчет таймаутов? Старт, стоп, время работы (актуально для oneshot юнитов). Это даже не команды. Это целые блоки кода и настройки.
- А что насчет приоритетов?
- Выставление юзера, группы.
- Смена шедулеров?
- Лимиты ресурсов?
- Capabilities минимально нужные? В системд - легко!
- А лишние сисколы seccomp-ом рубануть? См. выше.
- Namespaces aka контейнеры? Создать или присоседиться. А то и ОС туда задеплоить.
- Как насчет вачдогования живости процесса и прочих действий "а-ля нокиевский MCE"?
Для половина этих хотелок - целые блоки кода, а не команды. С обпрыгиванием кучи дурных грабель. Про которые с наскока можно и забыть со своим while true, между прочим. А потом, когда оно отвалится в боевой системе... ну в общем, я на такое насмотрелся. А фантомас в очках на аэроплане для скриптеров - все это сделать и при этом еще и залогить весь вывод и обработать все ошибки всех программ. А что, системд именно так и делает.
> А по факту, практически все ограничивается стандартными командами и их поведение более предсказуемо.
Я не знаю "стандартной команды" для логики вачдогования процессов. И не хочу выписывать целый блок кода для замера таймаута старта и убиения сервиса. В системд это 1-2 директивами делается. А за несколько лет - там обпрыгают (и уже многое обпрыгали) развеселые грабли вида "пришел ntp и крутанул часы в этот момент". А вам в вашем скриптодобре подобные грабли запросто укатают в лоб. Этак 29 февраля, високосного года, после дождичка, в четверг. Без диагностики "а какого оно так". И удачи поймать такой баг.
> unix way запрещает взять более подходящий архиватор, если изначально
> задача в извлечении отдельных файлов?
Общая логика процесса плохо накладывается на пайпинг: надо чтобы архивер и компрессор были одной сущностью, а не двумя и кооперировали более плотно чем это комфортно и логично делать через пайп. Компрессор должен быть file-aware и знать где оглавление. И форсировано сбрасывать состояния на характерных границах, удобных архиватору, чтобы позволить декодирование с именно этого места. А "слепой" компрессор, жмущий вход на выход - не дружит с идеей "достать файл из середины". А архиверу неплохо бы знать насколько сжался "вон тот файл". Чтобы к "вот этому файлу" информированно отмотать за разумное время. Не декомпресся и даже не читая весь 100-гиговый файл.
Делать квази-RPC к компрессору, с директивами сброса состояния проталкиваемыми через пайп - наверное можно, но - изврат. Сложно и криво. И уже не юниксвэй, т.к. произвольный компрессор уже не прокатит.
> Запускал + перезапускалка сервисов.
То как оно это делает - из разряда "и даром не возьму".
> Остальное - задача сервисов и приложений.
Ну конечно, все прогеры в восторге требовать старт под рутом, со всеми CAPSами и далее лично кодить кучу системной логики, типа смены шедулеров, приоритетов, юзерей и прочая. Они мечтают возиться с отсоединением std*, париться с уталкиванием себя в новый namespace, и уж конечно какой же програмер откажется написать вачдог-супервизор процесса. А это - вовсе и не сарказм.
> которые я постоянно использую.
Ну как, они опциональны. Без них можно обойтись. Если форсить логику зилота по экономии ресурсов - надо их срубить. Так что не надо их использовать.
> Да и все ядро жрет памяти примерно столько же, как udev+dbus.
А браузер может скушать в 100 раз больше. И?
> Хватает. Можете погуглить.
А мне это зачем? Я больше всех хочу попрыгать по нестандартным граблям, убив много сил ради маргинального выигрыша?
> висит, гибкий простой, хорошо поддается дебагу - даже не знаю чего еще хотеть.
А мне 2 метра памяти на udev обычно жить не мешают. Кроме урезанных железок, где уместен openwrt. Но там обычно большой напряг с хорошей поддержкой оборудования и плагнплеем как таковым. Т.к. для начала - в девайсе нет места на все драйверы, скажем, usb-девайсов.
> Это проблемы дистрибутива (его особенностей или кривых рук).
Это скорее общее сочетание свойств дистра с железками на которых есть смысл его применять. Они сами, прямым текстом пишут что на девайсах с >=128Мб памяти и гигазом NAND есть смысл смотреть на более полноценные дистры, типа дебиана.
> Не вы меня за человека не считаете? Естественно хотплаг у меня работает
С учетом ваших странноватых предпочтений - я это могу предполагать только после явного уточнения.
> и вроде я об этом уже вам рассказывал в предыдущих дискуссиях.
Извините, значит я это прошляпил.
> монтирование флешек сделал с предварительной проверкой fsck
Во, логика мамонта: вместо устранения root cause - сделать костыль. При том если флеха большая, а файл нужен быстро - ну да, именно fsck в этот момент и не хватало.
> (патченный для полного автоматизма).
ИМХО это довольно спорная идея. Не говоря о том что человеческое решение было бы использовать ФС которая не разваливается при выдергивании флехи наобум до состояния когда надо полный fsck. Вы же выключаете какой-нить домашний роутер отключением питания и не паритесь что встроенная ФС слетит. И никаких fsck там нет.
> И другие подобные штуки.
Все это же можно и на udev сделать. Я себе сделал рандомизацию мак-адресов на беспроводных интерфесах, например. При появлении и-фейса. И переименования ифейсов напрочь переиначил.
> Не оборвать, а сделать опцией!
Если насчет udev я еще со скрипом могу согласиться, хоть выигрыш от этого мне и не очевиден, то вот нормальную системную шину с точки зрения программирования я бы хотел видеть "условно-mandatory". Ну то-есть если и обрываемой то только в совсем low res эмбедовке а-ля openwrt. Иначе програмить это потом хреново будет.
> Простое, если не растягивать ;) Если поставленные задачи выполняются без чего либо,
Выполнять задачи можно по разному. Говорю же - можно и ядерные треды оборвать при сильном желании. Выполнять все сисколы синхронно, по мере поступления. Работать же будет!
А такие параметры как качество работы (в утрированном примере с сисколами - латенси, многопоточность, etc) у вас в метриках совсем не фигурирует. Вот sysv init - примерно так же, как оборвать ядерные треды и сделать пещерную, синхронную, 1-поточную реализацию сисколов - "можно обойтись" же. Ну, обходитесь.
> А мало разбирающиеся люди потом клепают PA only приложения :(
А им даром не упало разбираться в интимных проблемах алсы. Люди хотят проигрывать звук, а не сношаться с интимными особенностями звуковух, алсы, их опциональных довесков или чего там еще. И даже libSDL, абстрагирующая все и вся, от OSS до WinAPI - предпочтет при наличии пульса и алсы задействовать пульс, что как бы намекает что горлопаны с опеннета выдают желаемое за действительное. А на практике с пульсом проблем меньше чем с алсой.
> А по факту почти всем приложениям приходится поддерживать не только alsa и jack, но еще и pa и oss.
При том Jack используют только узкоспециализированные приложения. На OSS почти все забили. А немало программ, натурально PA-only. Для особо упертых зилотов вроде даже какой-то костыль есть для вывешивания алсой пульсовского апи. А для меня, pulse - worksforme, обеспечивает ряд полезных мне фич и никаких проблем мне на моей памяти не создавал. Поэтому потоки помоев в адрес пульса я считаю преувеличенными и иррациональными.
ИМХО, когда некто начинает страдать контрпродуктивными предрассудками и чрезмерной разборчивостью - пусть они и бодаются с костылированием. Так вполне честно.
> Нет просто избегать жесткой привязки там, где без нее можно обойтись.
Я в общем случае как-то совсем не рвусь сконвертировать чужие чудачества и предрассудки в мои сложности. Поэтому если некто уже накодил нужную программу, либу или что там еще - я вполне могу это задействовать, если это упростит мне жизнь. Я в курсе что махать факом все время - не лучшая идея. Но другой стороны, плохо и когда всякие умники с нахрапом садятся на шею и начинают качать права, рассказывая кто и что "должен". Реально будет тот или иной баланс и сильно махать требованиями перед програмерами и майнтайнерами - не получится.
> Это нормальная практика и вся низкоуровневая часть ее придерживается. Пример с mesa
> уже приводил.
Случаи бывают разные. Разумеется, специально ломать совместимость - свинство. Но и усложнять себе жизнь без ощуимого выигрыша - мало кто мечтает. А за ВСЕХ расписываться к тому же нескромно и чревато уличением во вранье.
> то, что необходимо для решения текущих задач.
Для general purpose систем множество задач не является четко определенным и избежать некоего оверкилла и оверхеда, являющихся расплатой за универсальность - не получится.
С точки зрения оптимальности, оптимальнее всего испечь ASIC рюхающий "эту задачу". Минимально возможным числом транзисторов, с максимальной скоростью. Но есть нюансы...
> Ну и смысл тратить на них память?
Для меня вопрос ставится иначе: "какой смысл возиться с экономией 2Mb RAM по линии udev'а на большинстве железяк?" Ответ на этот вопрос я знаю только для совсем мелких девайсов на которые ставится openwrt...
> Да, но ее все же будет больше, а вероятность свопа меньше.
В общем случае я считаю что своп должен умереть. Особенно на механические hdd. На дворе 2015 год, RAM нынче емкий и дешевый. И нет никакого смысла эмулировать недостающий RAM тормозным hdd, у которого с random access плохо. В лине, правда, есть парочка интересных вещей. Скажем, ZRAM. А вот своп на механику - плох для latency программ. Это неприемлимо ни для десктопов, ни для эмбедовки, ни для серверов, по большому счету.
> Естественно, оптимизация должна быть комплексной и избавление от d-bus/udev это только
> ее малая часть.
ИМХО, настолько ядреный уровень оптимизации имеет смысл лишь в сильно некоторых системах и по сильно некоторым поводам. А окучивать так обычный десктоп - контрпродуктивно.
> А по факту - браузер palemoon (дополнительно зачищен при сборке). Ест в
> среднем 150-300MB + 20MB система.
И ваши 2 мега идут лесом, когда невъ... XUL-ятина и явоскриптятина запускается. И скриптокидозники делавшие вон тот сайт - не парились как вам 2 мега сэкономить на их сайте.
> 2GB памяти. Ее хватает чтобы не закрывая браузер работать со звуком или графикой,
Смотря что понимать под "работой с графикой". Вон например DarkTable для хорошей работы хочет побольше ядер проца и побольше памяти под кэши. И на 8-ядернике с 16 гигз он работает сильно резвее чем на 2 ядрах и 2 Гб RAM. К тому же, дисковый кэш на несколько гигов - уменьшает seek механики и протирание ssd. Он и от OpenCL не откажется, охотно выпихнув тяжеленные и параллелящиеся операции на GPU. Это - работа с графикой, 2015 год.
> не залазить при этом в своп.
У меня обычно нет свопа на механических дисках. Я себе не враг.
> Уже, лет пять - и как вы говорите: ЧСХ без проблем работают
А я недооценил вас как маньяка оптимизации.
> Busybox с конфигом под десктоп
... - "взаимоисключающие параграфы" :)
> 387KB, нет смысла его сильнее кромсать.
Такому размеру роутеры позавидуют. Но что ни говори, а даже в полной сборке утилсы из бизибокса обрубленные, упрощенные и имеют меньше опций. Они, конечно, нужны не всегда. Но если опции нужны, а их нет... упс.
> Да, но некоторые пакеты при сборке страдают башизмами.
И утилиты в бизибоксе урезанные. Большинство сетевых утилсов там очень упрощенные. И если на роутере изучать "а что он вообще делает" каким-нибудь netstat приходится редко, то на десктопе это куда более частое явление и имхо можно позволить себе нормальные утилиты. Я ж не ставлю целью влезть в 32Мб RAM при том что 20 уже съело ядро и прочие бизибоксы :)
> Да и виртуальная консоль в mc нормально без баша не работает.
Вот только один баш весит как 2-3 ваших бизибокса :)
> А так да - инит скрипты на простом шеле.
Да и фиг с ним. Я с удовольствием забуду про это безобразие как страшный сон.
