Трудно сказать - баг это или киллерфича... Время покажет, наверное.
Но для многих (и для меня в частности) такое поведение udev/systemd стало неприятной неожиданностью.
Наверное обывателю, который в системные потроха не лазит, а просто пользуется все такие изменения - по барабану. Но беда то в том, что Linux чаще всего используют именно "необыватели", которые любят в потрохах системы покопаться. :)
Для коммуникации с демоном можно использовать много чего (можно выбрать что удобнее тут стандартов особых нет).
kill - 'это в принципе - довольно грубо(там еще важно послать правильный сигнал и корректно его отработать, что бы он демона не прикончил). Но довольно универсально.
Можно демону привесить простенький http сервер и слать ему запросы.
Можно организовать общение через сокет (pipe).
Вам нужно разделять понятие демона и скрипта. Демона вы должны создать одним запуском скрипта, в нем должен быть форк если вы рассчитываете вернуть управление вызывавшему. программа же для управления демоном - это кораз то что должно есть команду в параметрах командной строки.
Демон и управляющая программа могут быть совмещены в одном скрипте/программе и поведение будет отличаться в зависимости от переданной в командной строке команде.
Так делают всех нормальных демонов: запуск без параметров - либо ошибка (если запуск нужно явно указать командой) либо запуск демона с возвратом управления или без. А вызов той же программы с параметрами типа stop, stat и т.п. будет просто обращаться к уже запущенному демону.
Для организации общения с демонами служит команда kill (со специальными сигналами) + обработчик в коде который реагирует на прерывание процесса и реагирует в зависимости от сигнала переданного в прерывании.
Тут вопрос в ресурсах.
Если есть дешевые разработчики и море времени, то можно по новой и виндовс переписать.
А если нужно быстро решить конкретную задачу, то всегда смотрят на готовые решения в первую очередь. И уже если нет удовлетворяющих готовых решений то тогда - безвыходно - разработка.
Разработчик в готовом решении никогда не будет заинтересован если только он не очень хорошо знает саму эту систему, бо ему лучше свое с нуля своять чем в чужом разбираться (когда потребуется править или дорабатывать). Да деньги за целую систему и за доработки существующей - совершенно разные. Тем более если на рынке доработок доя CMS и так довольно большая конкуренция.
Т.е. на мнение разработчиков - нужно обращать внимание по столько, по скольку важны отношения с ними. И нужно учитывать их интересы в оценке их суждений (в любом случае).
CMS - это не язык программирования - это Content Management System - смистема управления контентом сайта. Так вот таких систем с указанными модулями - чуть больше чем сотня. Выбрать можно на любой вкус и бюджет. Если бюджета нет - то и брать надо бесплатные (обычно опенсорс) решения - дальше только настройка, а настроить там можно очень сильно. Самих модулей/плагинов с поддержкой всяких досок объявлений - в каждой CMS обычно не один, а для некоторых их десятки.
Сам давно использую XFS и еще ни разу с ней проблем из-за отрубания питания у меня не случилось. Более того - внешний диск с XFS спецом выдергивал из разъема во время работы - так и не смог добиться разрушения ФС как не старался. Наверно мне просто сильно везет, а вам - наоборот :)
С уезжанием в сторону - вообще непонятка (каюсь сразу не рассмотрел).
Тут такое впечатление что слетело позиционирование именно для операции разворачивания... честно говоря - трудно понять откуда могло взяться такое смещение.... с другими мониторами не баловались? Откуда сам XFCE брали? Как ставили?
Python 2.7.6 (default, Jun 22 2015, 17:58:13)
[GCC 4.8.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> filter(lambda c: c.islower() or c.isdigit(), 'asd123ASD!@#')
'asd123'
>>>
В третьем:
Python 3.4.3 (default, Oct 14 2015, 20:28:29)
[GCC 4.8.4] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> filter(lambda c: c.islower() or c.isdigit(), 'asd123ASD!@#')
>>>
т.к. в третьем строже обработка и filter - это итератор, а не функция как в питоне2.
И да, в 3-м нужно мудрить с преобразование итератора возвращающего отдельные символы.
Kimiguro: да - есть от основ различия, но они скажем так - поверхностные (т.е. сразу в глаза бросаются), а вот работа с Unicode строками и байтовыми массивами - эта разница она, скажем так, "внутренняя", не на поверхности - но эти грабли очень больно бъют по лбу.
Японский Городовой: тут далновидность - дело десятое - те кто покупают пром-оборудование про то что контроллеры программировать можно только на винде - просто не думают. Для них это не ограничение.
Вот так и получается что в 2015 году на одном крупном заводе есть специальный ноутбук с Win95 для работы с оборудованием под которое больше никакого софта нет кроме как под вынь95.
А в целом - согласен: под Linux уже довольно много микроконтроллерных платформ можно программировать нативными средствами.
Но для многих (и для меня в частности) такое поведение udev/systemd стало неприятной неожиданностью.
Наверное обывателю, который в системные потроха не лазит, а просто пользуется все такие изменения - по барабану. Но беда то в том, что Linux чаще всего используют именно "необыватели", которые любят в потрохах системы покопаться. :)