> может влиять на работу запускаемых приложений.Если вы хотите систему, где вообще никто, никогда и ничего не меняет параллельно с вами - используйте MSDOS.
А в многозадачке потенциально всегда может что-то меняться. Глупые люди имеют свойство на это забивать. А потом - какой-нибудь ntp приходит и переводит часы. Ну а гомнокод от таких умников или висит неделю как тряпочка, или внепланово срабатывает. Досявое мышление заканчивается так.
> Например один демон, который я писал, сам для себя выставляет cgroup, seccomp и прочее.
Только это геморно и тех кто это делет - очень мало. А мне теперь не придется заниматься выписыванием такого кода в каждом первом сервисе.
> привет от Леннарта.[/offtop]
Все бы ничего, но
1) Леннарт уже давно этим не занимается.
2) Знаете, когда в алсе кто-то монопольно занял девайс - тоже не сильно понятнее что и кто.
> Чем OpenRC не устраивет?
Это "sysv init на стероидах". Зачем мне это? Systemd - решает мои проблемы администрирования. Просто и комфортно в большинстве случаев. Он не запрещает вызывать внешние скрипты для реализации сложной логики. Но на мое мнение сложной логики в стартовой последовательности системы быть должно минимум. Иначе потом через 2 года мозг сломаешь "откуда же это берется?".
Поттеринг взялся разруливать проблемы администрирования. И у него это получилось. Лучше чем было до него. За это он и симпатичен такой толпени майнтайнеров и разработчиков. А OpenRC что пытается сделать? "Sysv init с заплатками"? Спасибо, но мне это не надо. И даже задачи "как прикрутить syslog-ng" у меня нет. У меня задачи иначе формулируются: "как залоггить сообщение" или "посмотреть сообщения от somecrapd за последние полчаса".
> И даже какой-то supervisor туда тоже впиливали. Хотя ниразу им не пользовалсяс.
Зато им пользуюсь я. И весит это меньше, чем shell гоняющий while true. И не висит в списке процессов левыми процессами шелла. И в отличие от - в курсе множества failure modes. Взвис на старте? Взвис при остановке? Взвис в run time? Вываливание с кодом ошибки? Затык ребута? Системд в курсе что так бывает. А while true надо превратить в большой блок кода, с конфигурацией, чтобы он стал сколь-нибудь эквивалентным. Нафиг надо.
> Какое удивление? О чём речь? Ниразу при передаче/получении сервера у меня не
> было таких проблем.
Зато я видал как черти-как писаный гомнокод работает. В том числе и супервизор отпадения сервиса писаный на кроне и шелскрипте. Ненене, дэвид блейн, мне шапочные взгляды на это логичнее и симпатичнее.
> не помогут защитить сервер от тонны нечитаемых костылей.
Однако, с системд заниматься непотребством будет более некомфортно. Это уменьшит частоту проблем.
> Тем ни менее насколько сложно будет пользоваться systemd, если заменить udev наместо mdev?
Systemd, как я понимаю, технически udev для работы не требуется. Насколько это сложно обтяпать и какие там будут грабли - я не знаю. А зачем мне такая конфига нужна? У этого есть какое-то рациональное real-world обоснование, не высocaнное из пальца?
> openrc-шные скрипты минимальны по своему размеру.
А там как обычно, да? Ну там забили на логгинг кодов возврата, сохранение в лог вывода программы при ошибке, всякие там таймауты и прочие вещи, без которых не понятно "почему ничего не работает" и много глупых грабель на ровном месте.
> специфичной настройки контейнера -- это был очень неприятный момент.
Сел я тут в автобус. И узнал что он оказывается не может заехать на горную вершину. Облом, однако. Оказывается, автобусные маршруты прокладывают там где кто-то еще и ездить будет. И не 10 человек в год. И есть технические ограничения.
> Да, уже исправили, но было неприятно.
У всяких sysv init - случаются затыки даже с очень простыми и очевидными системными хотелками. Начиная от понимания "откуда это берется?" до реализации вачдога, таймаутов или логинга кодов возврата и вывода программы. Не говоря уж про всякие seccomp и смены шедулеров.
> привело к зависанию системы, то перезагружать до тех пор, пока хакеры
> не подберут правильное смещение -- это самый плохой подход.
Ребут - достаточно заметное событие. И если это сервер и он нормально админится, админ должен бы заинтересоваться почему там много ребутов подряд. А еще - journald'шные логи проблематично подтереть задним числом. А текстовые - запросто. Стереть строку с "своей" записью много ума не надо. Это будет полностью незаметно для админа. Сказ про ремотный логгинг - круто, но - другие допущения. И еще: кто будет проверять проверяющего?
> И существует тонна других примеров, когда не нужно ничего автоматически перезапускать.
ЧСХ, в systemd автоматический перезапуск - штука опциональная. Зато когда становится надо - очень хорошо, что так можно. И еще лучше что все это настраивается.
> Если произошла ошибка -- с ней обычно нужно сначала разобраться.
Это "обычно" может весьма варьироваться. Может быть автопилотная инсталляция, где с ошибкой разбираться некому. Более того, таких инсталляций много. У поттера почему-то есть нормальный тулинг для всего этого. И он в отличие от - решает проблемы, а не лечит что такие юзкейсы требоваться не должны. За это он получает 5 очков форы перед конкурентами.
> Достаточно редко бывают другие ситуации.
На один твой пыльный сервер - две дюжины юнитов эмбедовки и околоэмбедовки. Где категорически некому жать ресет и изучать ошибки.
> Не надо строить полных аналогий между электросетями и системным администрированием.
Тем не менее, некоторые инженерные практики местами перекликаются. Никто не хочет гнать человеков за тридевять земель чтобы нажать ресет на какой-то дряни.
> Всё-таки совершенно разные вещи.
Но есть кое-какие схожие требования: постоянная работа. С минимальным обслуживанием, по возможности.
> Электросети не обрабатывают данные,
Это тебе так кажется. Подумай о том что в сети 50Гц все генераторы должны быть идеально синхронизированы. А стыковка больших систем и перераспределение нагрузки по хорошему довольно интеллектуальные операции требующие приличной аналитики и умной реакции.
То что так не всегда и не везде - скорее сделствие исторических причин. Пока не было лопат - пользовались палкой-копалкой. А когда поняли что лопаты порой маловато - сделали экскаваторы.
> которые могут корёжиться после каждой перезагрузки, их не взламывают и т.п.
У них периодически случаются факапы. Там провод оборвался, там хак...воры провод сперли. А вон трансформатор #$%нул. И очень кстати если grid в целом еще и не завалится от подобных вещей, еще более кстати если grid будет уметь перекоммутировать нагрузку и взаимодействовать с другими grid-ами.
В любом случае, у них тоже бывают transient и permanent сбои. И им тоже не хочется бегать и обслуживать что-то, если этого можно избежать.
> А бывают ещё задачи кроме тех, которые выполняете вы.
Ну разумеется.
> Где, например, намного эффективнее реализовывать высокую доступность через избыточность > серверов, а баги рассматривать вручную и исправлять, вместо перезапусков.
Так я что, против? Просто это дороже. И у них обычно системы тоже ориентированы на бесперебойную работу, прежде всего. А анализ ошибок - может быть. Но в большой инфраструктуре всегда будет эн проблем. Если у вас миллион серверов - где винч сдох, где-то память глючит, где проц барахлит, где питальник помер. При этом просто меняется юнит администрирования: сервак могут просто заменить целиком. А детальные изучения что и почему - таки обычно не в живой структуре, а в фоне и сбоку. Кстати VM по этому поводу всем нравятся, с ними так проще всего. И развязка логики от физики. И системы по этому поводу раскатывают из шаблонов за минуты в общем случае.
> полезные данные, а без перезагрузки всё бы прошло само через несколько минут.
Иногда вачдог может быть и не тем что хотелось. Но тем не менее, затык активности на несколько минут - это в общем случае ошибка программирования. Система не должна вставать колом на несколько минут, имхо. Ну то-есть есть энное количество задач где такая латенси приемлима, но по дефолту я такое считаю ошибкой программирования или администрирования.
> Watchdog нужен только там, где он действительно нужен.
Со своей стороны я в общем случае считаю время реакции системы измеряемой МИНУТАМИ жирным багом программирования, который надо чинить.
> Не надо все задачи в мире равнять на ваши.
Вот к себе это и примените. В случае системды - там опций на разные задачи почему-то есть. И перенастраивается изрядно.
> Так и не надо их совмещать без необходимости.
Ну так у микроконтроллера - ограничение по ресурсам. Он не может считать как апликушный проц.
> А МК ещё более приличную. И стоят гораздо дешевле. Какой-нибудь STM32F0xx стоит
> порядка 50р (в текущими курсами валют)
Да я в курсе :). Урвал мелкооптовую партию таковых, по $0.8 и иному курсу. Мне их теперь надолго хватит. Но вот вебфэйс я так делать не буду. И картинку с usb-камеры на sata hdd я так записывать не стану. И по PPTP через эзернет я на МК конектиться не буду. И с сотовым модемом разве что с промышленным модулем работать. Совсем не ширпотребная штука и не очень дешевая. И GPRS-only в основном. А хотя-бы 3G - уже совсем отдельная сказка. С отдельной ценой. Usb-свисток из ближайшего ларька дешевле и шустрее. И еще вопрос кто менее надежен.
> без реальной необходимости -- это просто растрата.
Смотря что понимать под реальной необходимостью. Тем более что Pi - готовое устройство. А для STM надо печатную плату. Для себя я условно-бесплатно наЛУТаю. Но вот пуск в производство платы - время и $. Инженерные решения - о выборе разумного набора компромиссов.
> Вообще-то камеру к МК приделать можно.
Но вот ресурсы там - не те. И фиг вы 720P@30FPS в реальном времени обсчитаете. И винч на терабайт не прицепите без отдельных извратов. И камера потребуется экзотичная.
> А сохранять на SD-карту так вообще легкотня.
При том обычно на дрянь типа FAT. С никаким разрешением. И кучей дурных ограничений. И картинка вида "китайский тетрис снимает лучше".
> Вам принципиально, чтобы камера была именно USB, а устройство хранения -- HDD?
Мне принципиально, чтобы параметры были конкурентоспособны, по разумной цене, с разумными затратами времени и сил. А "тетрис" с массой ограничений, требующий времени разработки в 5 раз больше - вы и разрабатывайте.
Сильный кодек типа H.264 (или VPx) на мк крутить не выйдет. И картинку в браузер не передашь. И алерт на почту "тут какое-то движение" из мк передавать неудобно. Особенно когда хочется чтобы адрес почты юзер мог бы и конфигурировать без мытарств.
> (никогда не интересовался такими решениями и сходу не знаю как тут дела обстоят).
Как я уже сказал, любое решение - набор компромиссов. Да, можно прицепить камеру к МК. Но только вот не забудьте поинтересоваться какой там объем данных при человеческих разрешениях и FPSах. А заодно подумайте как это выплюнуть в сеть и как сделать чтобы юзер мог перенастроить емыл без мучений.
> Кстати говоря, кроме камер бывают и другие датчики.
Ну вот поэтому до кучи может хотеться поклацать каким-нибудь реле. И не всегда там злые требования к реалтаймности и прочая. Разумеется, обмотки BLDC коммутировать апликушником будет лишь дypaк или извращенец.
> И зачем тут винчестер?
А потому что на него влезет уйма видео с приличным качеством за солидное время. И он не загнется от активной записи, в отличие от SD карты.
> Я вот недавно закупил Wi-Fi модулей по 160р.
При том там хзкакая проприетарная прошивка, неизвестной степени безопасности, в 5 раз сложнее фирмвары вашего МК. С кучей дурных допущений и ограничений. Что ни говори, а у линуха сетевой стек развитее. И - опенсорсный. Как инженер - я не подпишусь за сетевую безопасность черти-какого модуля с мегабайтом проприетарного кода, реализуюшего протокол.
Ну и сделали вы девайс. И как юзеру его настраивать в человеческом формате, интересно? Ну там хоть параметры беспровдной сети вбить.
> Можно пример задачи, где не хватает МК, чтобы понять о чём конкретно сейчас речь?
Любая задача где:
- Развитое конективити в нормальные сети, без глупых ограничений.
- Обработка существенного объема данных или интенсивная математика. Сильные кодеки, шифрование, etc.
- Сколь-нибудь развитый юзеринтерфейс.
- Нужда или желание работать с "большой" PC-образной периферией.
В результате - с практической точки зрения, предложенные вами решения - геморны в реализации и обладают хреновыми параметрами и неудобны для пользователя. И при небольшом тираже, удешевление юнита ценой увеличения времени разработки это FAIL. А продать миллион таких уpoдцев, где мк с камерой - ок, попробуйте.
> И ответьте, пожалуйста на мои вопросы тут:
Вроде ответил.
