>> может влиять на работу запускаемых приложений.
> Если вы хотите систему, где вообще никто, никогда и ничего не меняет
> параллельно с вами - используйте MSDOS.Причём тут параллельный запуск? Я говорил вообще-то про последовательные операции (сначала изменить cgroups, а потом запустить), а не параллельные.
Но даже если так, что MSDOS — это как минимум не свободное решение, которое абсолютно не решает моих задач чисто технически.
> А в многозадачке потенциально всегда может что-то меняться. Глупые люди имеют свойство
> на это забивать. А потом - какой-нибудь ntp приходит и переводит
> часы. Ну а гомнокод от таких умников или висит неделю как
> тряпочка, или внепланово срабатывает. Досявое мышление заканчивается так.
So what? Вы это вообще к чему?
>> Например один демон, который я писал, сам для себя выставляет cgroup, seccomp и прочее.
> Только это геморно и тех кто это делет - очень мало. А
> мне теперь не придется заниматься выписыванием такого кода в каждом первом
> сервисе.
У очень многих приложений могут быть свои особенности вызывающие те или иные проблемы. А когда основная системная запускалка — это мегамонстр, который любит отвечать тупо "Connection refused" вместо подробного описания проблемы, то это сильно усложняет лично мою жизнь. Да, я действительно использую systemd на некоторых системах. Думал, что может привыкну и станет лучше, а оказалось, что привык и понял, что всё ещё хуже, чем я думал.
>> привет от Леннарта.[/offtop]
> Все бы ничего, но
> 1) Леннарт уже давно этим не занимается.
Ну да, он любит бросать проекты. Когда systemd тоже бросит и тот тоже начнёт себя так вести, то что?
Когда в pulseaudio был Леннарт, это был глюкавый падучий пш-пш. А когда Леннарта не стало — стало лучше, но вот DISPLAY недавно порадовал. До этого проблемы с bluetooth очень порадовали и многое другое.
> 2) Знаете, когда в алсе кто-то монопольно занял девайс - тоже не
> сильно понятнее что и кто.
Не понял этот тезис. Что значит «понятнее что и кто»? Речь про «lsof -n /dev/snd/*»? Я вообще любитель OSS, но на Linux пользуюсь ALSA из-за размера комьюнити (да и на нём тоже можно жить). PulseAudio ничего нового (из полезного) толком не изобрёл. Вообще не хотел бы ещё и на эту тему тут спорить, вы и так пишите очень много текста, что заставляет тратить очень много времени на тупо набор текста-ответа.
>> Чем OpenRC не устраивет?
> Это "sysv init на стероидах". Зачем мне это?
Затем, что он хорошо решает задачи, сохраняя прозрачность и хорошую полноценную модульность. И появился раньше, и управляется/развивается полностью свободным сообществом а не RH.
> Systemd - решает мои
> проблемы администрирования. Просто и комфортно в большинстве случаев. Он не запрещает
> вызывать внешние скрипты для реализации сложной логики. Но на мое мнение
> сложной логики в стартовой последовательности системы быть должно минимум. Иначе потом
> через 2 года мозг сломаешь "откуда же это берется?".
OpenRC тоже решает проблемы комфортно администрирования без искусственной необходимости ручного описания сложной логики.
> Поттеринг взялся разруливать проблемы администрирования.
Которых и так не было, IMHO.
> И у него это получилось. Лучше
> чем было до него. За это он и симпатичен такой толпени
> майнтайнеров и разработчиков. А OpenRC что пытается сделать? "Sysv init с
> заплатками"? Спасибо, но мне это не надо. И даже задачи "как
> прикрутить syslog-ng" у меня нет.
Рад за вас.
> У меня задачи иначе формулируются: "как
> залоггить сообщение" или "посмотреть сообщения от somecrapd за последние полчаса".
Это просто другие задачи.
>> И даже какой-то supervisor туда тоже впиливали. Хотя ниразу им не пользовалсяс.
> Зато им пользуюсь я. И весит это меньше, чем shell гоняющий while
> true. И не висит в списке процессов левыми процессами шелла. И
> в отличие от - в курсе множества failure modes. Взвис на
> старте? Взвис при остановке? Взвис в run time? Вываливание с кодом
> ошибки? Затык ребута?
Это всё не имеет отношения к OpenRC.
> Системд в курсе что так бывает.
И при этом сам при некоторых условиях успешно зависает.
>> Какое удивление? О чём речь? Ниразу при передаче/получении сервера у меня не
>> было таких проблем.
> Зато я видал как черти-как писаный гомнокод работает. В том числе и
> супервизор отпадения сервиса писаный на кроне и шелскрипте. Ненене, дэвид блейн,
> мне шапочные взгляды на это логичнее и симпатичнее.
>> не помогут защитить сервер от тонны нечитаемых костылей.
> Однако, с системд заниматься непотребством будет более некомфортно. Это уменьшит частоту
> проблем.
Он просто их абстрагирует. И если будут проблемы, в которых уже учавствует systemd, то диагностировать их становится уже сложнее, ибо это монстр который творит много всего.
>> Тем ни менее насколько сложно будет пользоваться systemd, если заменить udev наместо mdev?
> Systemd, как я понимаю, технически udev для работы не требуется. Насколько это
> сложно обтяпать и какие там будут грабли - я не знаю.
> А зачем мне такая конфига нужна? У этого есть какое-то рациональное
> real-world обоснование, не высocaнное из пальца?
Когда-то, когда я жил на FreeBSD, у меня никогда не было проблем, что после обновления сетевые интерфейсы стали именоваться как-то через жопу, как и многих других проблем. Я вообще с монстрами менее эффективно работаю, чем с минималистичными решениями.
>> openrc-шные скрипты минимальны по своему размеру.
> А там как обычно, да? Ну там забили на логгинг кодов возврата,
> сохранение в лог вывода программы при ошибке, всякие там таймауты и
> прочие вещи, без которых не понятно "почему ничего не работает" и
> много глупых грабель на ровном месте.
[/me призывает:] Bircoph, ты как gentoo-dev ответь, пожалуйста. Вдруг я где-то отвечу неточно, случайно.
>> специфичной настройки контейнера -- это был очень неприятный момент.
> Сел я тут в автобус. И узнал что он оказывается не может
> заехать на горную вершину. Облом, однако. Оказывается, автобусные маршруты прокладывают
> там где кто-то еще и ездить будет. И не 10 человек
> в год. И есть технические ограничения.
Ну, мы занимаемся большим количеством кастомных решений (специфика нашего отдела такая). И я почему-то такой невезучий человек, что у меня постоянно с этим systemd много неожиданных проблем. Дошло до того, что мы были вынуждены всё-таки использовать для большинства систем openrc на Debian несмотря на малый комьюнити вокруг него (в Debian).
>> Да, уже исправили, но было неприятно.
> У всяких sysv init - случаются затыки даже с очень простыми и
> очевидными системными хотелками. Начиная от понимания "откуда это берется?" до реализации
> вачдога,
Какие проблемы с watchdog?
> таймаутов или логинга кодов возврата и вывода программы.
Вы пробовали OpenRC? Вы утверждаете, что то как сделано в OpenRC вас не устраивает, я правильно понял?
> Не говоря уж про всякие seccomp
С одной стороны:
- Вообще говоря, seccomp лучше всего настраивать после инициализации (после setuid()-ов, exec()-ов и всего лишнего, что не требуется во время работы и завершения). Поэтому seccomp должен использоваться внутри приложения.
- Внешний seccomp очень опасен для обеспечения работоспособности приложения. Обновилась версия ПО и начало оно использовать новые функции — и что дальше? Сменился libc и начал использовать другие syscall-ы для тех же самых функций — и что дальше? И т.п. На мой взгляд seccomp — это advanced security feature для advanced users, и включать его извне — это бред. Только автор программы настолько хорошо знает программу, что понимает как нужно настраивать seccomp.
С другой стороны:
Я согласен, что дополнительный слой защиты (даже если он хуже, чем мог бы быть) — это хорошо.
Теперь по сути:
- Это упущение, что нет отдельного seccomp wrapper в стандартных репозиториях того же Debian (хотя может быть он и есть, а я о нём просто не знаю). Если бы он был, то подключить его в OpenRC — элементарное дело. Это никто не делает лишь потому, что так не надо делать, IMHO, так как работы сис. админам сильно прибавится.
- Если говорить про очень грубу настройку seccomp (чтобы точно не мешать работе приложений), то она и так делается с помощью lxc, где у меня и развернуты все чувствительные сервисы.
В результате я не вижу какую проблему решил systemd своим появлением.
> и смены шедулеров.
Что имеется в виду под «сменой шедулеров»?
>> привело к зависанию системы, то перезагружать до тех пор, пока хакеры
>> не подберут правильное смещение -- это самый плохой подход.
> Ребут - достаточно заметное событие. И если это сервер и он нормально
> админится, админ должен бы заинтересоваться почему там много ребутов подряд.
Это может произойти в 3 часа ночи.
> А еще - journald'шные логи проблематично подтереть задним числом. А текстовые -
> запросто.
journald-шные логи подписываются что ли? Если бы даже было бы и так, то что сложного то же самое делать с человекочитабельными логами? Хотя лично у меня так вообще логи льются на отдельный сильнозащищённый сервер с syslog-ng, откуда уже никто ничего потереть не сможет.
> Стереть строку с "своей" записью много ума не надо. Это
> будет полностью незаметно для админа. Сказ про ремотный логгинг - круто,
> но - другие допущения. И еще: кто будет проверять проверяющего?
Что такое «ремонтный логгинг»?
>> И существует тонна других примеров, когда не нужно ничего автоматически перезапускать.
> ЧСХ, в systemd автоматический перезапуск - штука опциональная. Зато когда становится надо
> - очень хорошо, что так можно. И еще лучше что все
> это настраивается.
Вообще-то для OpenRC тоже есть решение на базе cgroups для опционального перезапуска приложений. Не знаю затолкнуто ли это в upstream — не интересовался уже давно…
>> Если произошла ошибка -- с ней обычно нужно сначала разобраться.
> Это "обычно" может весьма варьироваться. Может быть автопилотная инсталляция, где с ошибкой
> разбираться некому.
Исталляция чего? ОС? Зачём её перезапускать? И как её перезапустить с помощью systemd?
>> Достаточно редко бывают другие ситуации.
> На один твой пыльный сервер - две дюжины юнитов эмбедовки и околоэмбедовки.
> Где категорически некому жать ресет и изучать ошибки.
Можно конкретный use case (embedd-овый)?
>> Не надо строить полных аналогий между электросетями и системным администрированием.
> Тем не менее, некоторые инженерные практики местами перекликаются. Никто не хочет гнать
> человеков за тридевять земель чтобы нажать ресет на какой-то дряни.
>> Всё-таки совершенно разные вещи.
> Но есть кое-какие схожие требования: постоянная работа. С минимальным обслуживанием, по
> возможности.
И туева хуча несхожих требований.
>> Электросети не обрабатывают данные,
> Это тебе так кажется. Подумай о том что в сети 50Гц все
> генераторы должны быть идеально синхронизированы. А стыковка больших систем и перераспределение
> нагрузки по хорошему довольно интеллектуальные операции требующие приличной аналитики
> и умной реакции.
Речь про какой-то сельсин? Или про что конкретно?
А если говорить конкретно про нашу гос. контору, то она платит более 50млн. в год на электропитание, и у нас в электросети нет ничего того, о чём вы говорите. Совершенно никаких сложностей, все технологии дубовые.
> То что так не всегда и не везде - скорее сделствие исторических
> причин. Пока не было лопат - пользовались палкой-копалкой. А когда поняли
> что лопаты порой маловато - сделали экскаваторы.
Вот только чтобы забивать гвозди я дома держу обычный молоток («изобретённый» хрен знает когда), хотя бывают и более хитрые средства.
>> которые могут корёжиться после каждой перезагрузки, их не взламывают и т.п.
> У них периодически случаются факапы. Там провод оборвался, там хак...воры провод сперли.
> А вон трансформатор #$%нул. И очень кстати если grid в целом
> еще и не завалится от подобных вещей, еще более кстати если
> grid будет уметь перекоммутировать нагрузку и взаимодействовать с другими grid-ами.
Мне казалось, что это уже задача контроллеров (то есть программистов, а не электриков).
>> полезные данные, а без перезагрузки всё бы прошло само через несколько минут.
> Иногда вачдог может быть и не тем что хотелось. Но тем не
> менее, затык активности на несколько минут - это в общем случае
> ошибка программирования. Система не должна вставать колом на несколько минут, имхо.
> Ну то-есть есть энное количество задач где такая латенси приемлима, но
> по дефолту я такое считаю ошибкой программирования или администрирования.
Каждая задача требует своих инструментов. Watchdog легко прикручивается куда надо. Однако намного проще делать надёжную систему, когда она легко собирается из минимальных необходимых блоков без применения монстров, пытающихся решать сразу все проблему (и те что есть, и те, которых нет). Да, в systemd всё настраиваемо, но всё равно образуется много лишнего пространства для проблем; а многое для настройки требует пересборки.
>> Watchdog нужен только там, где он действительно нужен.
> Со своей стороны я в общем случае считаю время реакции системы измеряемой
> МИНУТАМИ жирным багом программирования, который надо чинить.
Бывают системы, где downtime пару часов — это приемлемо. Бывают системы, где доступность обеспечивается другими способами (а не перезагрузкой).
>> Не надо все задачи в мире равнять на ваши.
> Вот к себе это и примените. В случае системды - там опций
> на разные задачи почему-то есть. И перенастраивается изрядно.
Это монструозная абстракция, которая лично с моей точки зрения (с точки зрения моих use case-ов) поборола уже n-ую ветряную мельницу. Я на своих системах уже отловил немало багов. В частности из-за работы с seccomp и многим другим. И нафига это всё было нужно, если openrc решает мои задачи не хуже (с точки зрения затрат моих человекочасов), но таких проблем не создаёт?
>> Так и не надо их совмещать без необходимости.
> Ну так у микроконтроллера - ограничение по ресурсам. Он не может считать
> как апликушный проц.
Это понятно, но всё равно можно конкретный use case? Я просто не сталкивался с задачами, куда не смог найти микроконтроллер с нужной производительностью. Вот найти АЦП за хорошую цену с нужной частотой выборки — это другой вопрос, но это уже другая тема для обсуждения.
У меня была всего пара случаев, когда требовались большие ресурсы для выполнения конкретной задачи, в обоих случаях я просто пересылал данные с МК на сервер, где эти данные обрабатывались. В одном случае по ethernet, в другом случае — по bluetooth.
>> А МК ещё более приличную. И стоят гораздо дешевле. Какой-нибудь STM32F0xx стоит
>> порядка 50р (в текущими курсами валют)
> Да я в курсе :). Урвал мелкооптовую партию таковых, по $0.8 и
> иному курсу. Мне их теперь надолго хватит. Но вот вебфэйс я
> так делать не буду.
Согласен. Хотя видел такие извраты :). Однако для «вебфэйсов» есть полноценные серверы, зачем тут всякие embedded-ы и т.п.?
> И картинку с usb-камеры на sata hdd
> я так записывать не стану.
USB и SATA — это принципиально?
> И по PPTP через эзернет я на МК конектиться не буду.
Не удивлюсь, что бывают готовые библиотечки для чего-нибудь мега-популярного вроде Arduino или Nucleo (на mbed.org, например). Однако опять же PPTP — это принципиально? Не хватит Wi-Fi с WPA2 до сервера, который уже умеет PPTP?
> И с сотовым модемом разве что
> с промышленным модулем работать. Совсем не ширпотребная штука и не очень
> дешевая. И GPRS-only в основном. А хотя-бы 3G - уже совсем
> отдельная сказка. С отдельной ценой.
> Usb-свисток из ближайшего ларька дешевле и
> шустрее. И еще вопрос кто менее надежен.
Хотите сказать, что GSM-модуль стоит дорого?
>> без реальной необходимости -- это просто растрата.
> Смотря что понимать под реальной необходимостью. Тем более что Pi - готовое
> устройство. А для STM надо печатную плату.
Есть Nucleo для ленивых, но он дороговат (подходит скорее как платформа для разработки, чем для production-а, IMHO). А распечатать плату, если она уже разработана — IMHO, не проблема. Если не хочется самому печатать, то есть всякие там «Резониты».
> Для себя я условно-бесплатно
> наЛУТаю. Но вот пуск в производство платы - время и $.
> Инженерные решения - о выборе разумного набора компромиссов.
Понятно. Как всегда всё зависит от конкретной задачи. Можете всё-таки рассказать конкретные задачи, которые вы решаете, чтобы я наконец начал вас понимать? :)
>> Вообще-то камеру к МК приделать можно.
> Но вот ресурсы там - не те. И фиг вы 720P@30FPS в
> реальном времени обсчитаете. И винч на терабайт не прицепите без отдельных
> извратов. И камера потребуется экзотичная.
Такую задачу не решал, своего мнения для данного use case-а не имею, пока что. Однако зачем вообще решают такую задачу? Разрабатываете системы видеонаблюдения?
Когда для дома just4fun решал такую задачу, то да, применил RPi. Но не понимаю зачем мне такое могло бы пригодиться в production-е. Системы видеонаблюдения существуют и без наших разработок, а автоматика обычно не требует видеосъёмки — процесс можно контролировать автоматически и через другие датчики.
>> А сохранять на SD-карту так вообще легкотня.
> При том обычно на дрянь типа FAT.
Ну, мы — извращенцы и предпочитаем работать без файловой системы, если чисто логически речь про один поток данных.
>> Вам принципиально, чтобы камера была именно USB, а устройство хранения -- HDD?
> Мне принципиально, чтобы параметры были конкурентоспособны, по разумной цене, с разумными
> затратами времени и сил. А "тетрис" с массой ограничений, требующий времени
> разработки в 5 раз больше - вы и разрабатывайте.
> Сильный кодек типа H.264 (или VPx) на мк крутить не выйдет.
> И картинку в браузер не передашь.
Зачем это делать на чём-то кроме полноценного сервера/десктопа? Это не сарказм, вопрос искренний.
> И алерт на почту "тут какое-то
> движение" из мк передавать неудобно. Особенно когда хочется чтобы адрес почты
> юзер мог бы и конфигурировать без мытарств.
Так пусть МК как угодно сообщает в сеть о проблеме, а далее нужный сервер уже поймёт, что нужно отправлять письмо. Простите ламера (всё это сильно выходит за рамки моих основных обязательств).
>> (никогда не интересовался такими решениями и сходу не знаю как тут дела обстоят).
> Как я уже сказал, любое решение - набор компромиссов. Да, можно прицепить
> камеру к МК. Но только вот не забудьте поинтересоваться какой там
> объем данных при человеческих разрешениях и FPSах.
Я просто вообще не понимаю, зачем нужен большой FPS на таких системах. Если хочется посмотреть общее состояние дел, то достаточно и одной фотографии раз в минуту.
> А заодно подумайте как
> это выплюнуть в сеть и как сделать чтобы юзер мог перенастроить
> емыл без мучений.
Выплюнуть в сеть — как раз не проблема. AFAIK, можно даже, например, сделать полноценное решение на базе ESP-12E (используя внутренний МК).
>> Кстати говоря, кроме камер бывают и другие датчики.
> Ну вот поэтому до кучи может хотеться поклацать каким-нибудь реле. И не
> всегда там злые требования к реалтаймности и прочая. Разумеется, обмотки BLDC
> коммутировать апликушником будет лишь дypaк или извращенец.
Не понял связи. Я говорю о применимости МК для тех use case-ов, где многие предпочли бы использовать RPi-like, за счёт применения не тех датчиков, о которых они думали изначально. А вы говорите о том, чтобы использовать GPIO RPi-like для работы с реле, я правильно понял?
>> И зачем тут винчестер?
> А потому что на него влезет уйма видео с приличным качеством за
> солидное время. И он не загнется от активной записи, в отличие
> от SD карты.
А почему нельзя передать по сети? Это какая-то автономная видеокамера, которая находится где-то в лесу? Мне кажется что для этого уже есть много готовых решений (не обязательно всё переизобретать). Или они дорогие? Или речь про импортозамещение?
>> Я вот недавно закупил Wi-Fi модулей по 160р.
> При том там хзкакая проприетарная прошивка, неизвестной степени безопасности, в 5 раз
> сложнее фирмвары вашего МК.
Буду тестировать, но насколько мне известно — как раз-таки нет, там свой МК, который можно свободно программировать.
А вообще, в ваших сетевых тоже firmware проприетарный :). А многие сетевые так требуют даже, чтобы ядро ОС подгрузило проприетарный firmware. Но я не собираюсь использовать это как аргумент, просто напоминаю.
> Ну и сделали вы девайс. И как юзеру его настраивать в человеческом
> формате, интересно? Ну там хоть параметры беспровдной сети вбить.
Пока не сделал, сейчас занят отчётами :(. А юзеру и не нужно будет его настраивать, ибо устройство под конкретную задачу. Один раз настроим и будет работать много лет без вмешательств. Исходный код, платы и прочее опубликуем, конечно же.
>> Можно пример задачи, где не хватает МК, чтобы понять о чём конкретно сейчас речь?
> Любая задача где:
> - Развитое конективити в нормальные сети, без глупых ограничений.
Ограничение в 5 TCP-соединений — это глупое ограничение. Вам действительно на устройствах такого масштаба требуется 100500 соединений?
> - Обработка существенного объема данных или интенсивная математика. Сильные кодеки, шифрование,
Отправляйте на сервер и обрабатывайте там.
> etc.
> - Сколь-нибудь развитый юзеринтерфейс.
Юзер — это тупой юзер? Тогда прикручиваешь экран и кнопки. Если юзер — это админ/программист, то достаточно просто написать документацию и сделать код, который легко понять как конфигурировать. Если же требуется интерактивная работа по ssh, то тогда сам интерфейс можно делать на каком-нибудь сервере, который по простому протоколу командует МК что нужно делать. Если хочется настраивать устройство, присоединив к десктопу, то вполне можно сделать «няшную» GUI-ёвину, которая общается с МК нужным образом.
> - Нужда или желание работать с "большой" PC-образной периферией.
Возможно это желание берётся чисто из инерции мышления, а не из реальной необходимости.
> В результате - с практической точки зрения, предложенные вами решения - геморны
> в реализации и обладают хреновыми параметрами и неудобны для пользователя. И
> при небольшом тираже, удешевление юнита ценой увеличения времени разработки это FAIL.
> А продать миллион таких уpoдцев, где мк с камерой - ок,
> попробуйте.
Я просто так и не понял конкретной задачи.
Просто если это система масштаба RPi, то обычно она имеет «коннективити» и управляется удалённо без проблем, что уже делает всякие автоперезапускали далеко не всегда желаемыми. Если же это система более мелкого масштаба, то обычно хватает МК.
>> И ответьте, пожалуйста на мои вопросы тут:
> Вроде ответил.
Нет, но и не надо уже. И так текста много :)
Мы на самом деле далеко ушли от сути. Вы, если я правильно понял, утверждаете, что ваши подходы к работе являются более правильными, и они выполняются более удобно с systemd. Я же с этим спорю, и считаю, systemd обычно слишком монструозен и скорее вреден, чем полезен… Хотя, возможно, я уже просто потерял нить диалога.
Да, бывают use case-ы, где он хорош. Я вообще рад его появлению (всегда рад за СПО, когда там появляется что-то новое). Однако делать его по умолчанию, IMO, было ошибкой. Однако не мне это решать, а людям которые это заслужили — developer-ами соответствующих дистрибутивов. Поэтому я просто помог немного развитию openrc в Debian и пользую его. А когда меня пытаются убедить, что systemd — это хорошо, то я просто вспоминаю через что мне пришлось проходить в экстренном темпе и пытаюсь пояснить собеседнику, что systemd был хорош, пока он не был навязан простому пользователю, вроде меня.
