Смещения вообще не должно быть, т.к. оно скорее способствует травмированию. См. TypeMatrix как наиболее традиционно выглядящую. А если радикальные решения подходят, то Maltron или Kinesis Advantage.
Жаль, что в ноутбуки не ставят клавиатуры без смещения, например TypeMatrix вполне бы поместилась.
Если бы style check всегда настаивал на том, что вызов функции должен быть со скобочками ( a() )
Это вы привыкли к идее, что функция — это со скобочками. Почитайте про Smalltalk — от него Ruby очень многое почерпнул, станет понятнее, почему можно без скобок жить.
Чтобы понять, что у функции есть значимое возвращаемое значение
В большинстве случаев возращаемое значение в руби значимо, из этого и стоит исходить.
Если бы Crystal быстрее развивался, то легко бы потеснил Go. Но за Go стоят практически неограниченные ресурсы гугла и легионы разрабов на волне хайпа. У Crystal маленькая команда разработчиков и про него мало кто слышал :(
Я уже сам написал пару мелких проектов на Crystal, но инфраструктура слабая, shard'ов (внешних модулей) мало, комьюнити небольшое. Печально, конечно.
В моём личном сравнении Go vs Crystal последний по удобству выигрывает с отрывом. Именно за счёт рубевого синтаксиса.
распространяется с таким конфигом под systemd, который не в состоянии обеспечить стабильный перезапуск сервиса
Маинтейнеры тоже, бывает, не любят документацию читать. Вообще, это копипаста из дебиана (там тоже --daemon). По хорошему, надо бы баг зарепортить, конечно.
systemd очень богат ненужными фичами
Это сделано для совместимости, чтобы systemd-sysv-generator(8) нормально работал, потому что в случае с sysv init нормальное поведение — это форкающийся демон. Подозреваю, что в будущем эту штуку удалят.
runit поддерживает только сервисы
runit никогда не заявлял совместимость с sysv init, равно как не претендовал на его полную замену (хотя в радикальной конфигурации его вроде даже можно как init запускать, размуеется, переписав вначале все скрипты запуска сервисов).
И чья это вина
Ничья. Если бы openvpn упал в системе с sysv init его бы никто даже не пытался бы перезапустить.
падал без воскрешения, хотя иногда systemd его таки перезапускал
Потому что «проверенную временем» схему с форком и уходом в background надо безжалостно выпиливать везде где только можно. В случае с openvpn это опция daemon (её найти и удалить).
В вашем случае, скорее всего, openvpn форкался и в таком случае systemd может и не отследить, что сервис упал.
Ну, и некоторые юниты от разработчиков сервисов ущербные.
Ну да, например в mongod.service указано Type=forking, однако надо при первой же возможности от форка избавляться. Монга сама умеет в foreground стартовать.
когда какая-то монга при обновлении или переустановки переписывает твой собственноручно поправленный юнит файл.
А вы, надеюсь, правите не в /lib/systemd/system? Надо это делать в /etc/systemd/system, а пакетам, в свою очередь, туда лезть не нужно.
Решение? Общего не нашел,
Например, systemctl mask some.service и делаем свой unit с немного другим именем.
что нужно было бороться только со скриптом, а не с целой системой инициализации
С чем конкретно вам бороться нужно было? Вот минимально необходимый unit, чтобы сервис работал (причём, если не надо его запускать после ребута автоматом, то достаточно 2 первые строки):
Вы можете на shell'е написать менее чем в 4 строки скрипт для sysvinit?
Systemd вообще никаким образом не помогает от сдохших сервисов
Смотря как сдох. Если упал — будет перезапущен. А если процесс подвис, то это не для systemd задача. И кофе в постель он тоже не приносит.
фичи десктопных сред на систему инициализации
Какие конкретно?
не все авторы софта или ментейнеры дистров сами хорошо разбираются в systemd
Точно так же, как не разбирались в sysvinit скриптах. Вы их смотрели — там сплошная копипаста и костыли. Люди вообще не любят доки читать, зато транслировать чьи-то там слухи гораздо проще.
но пока его не поставишь, все работает и без него?
Так всё работает и с ним, в чём проблема? В том, что надо ещё десяток man'ов прочитать?
А потом появился myservice3, про него забыли и т.п. И про докер не надо, это уже другой уровень абстракции.
Просто любопытно, что конкретно делают эти юниты, откуда такие странные требования?
Ничего странного. Это случай из жизни — запускаем dehydrated для обновления сертификатов Let's Encrypt. Т.к. ему не нужны особые права, то запускаем от юзера. Потом надо от рута запустить reload сервисов, где сертификаты используются — для этого второй юнит, связанный с первым.
sudo? Ну ок, а если хочется ему ограничить права, например так:
Опять же, вспоминаем, что unit не может быть запущен параллельно два раза, что сплошь и рядом встречается при запуске из крона (да, для этого надо ещё костылей городить, проверять pid файлы и т.п.)
сколько бы фич не добавляли в systemd он всё-равно не сможет заменить все баш-скрипты
Задачи заменить все баш скрипты никогда не ставилось.
похожую картину можно увидеть запустив srvstat
А user.slice как вы увидите? Или «это не надо»? Напоминаю, что systemd загоняет все процессы (кроме кернел тредов, конечно же) в какой-то вменяемо названный cgroup.
Докер умеет.
Про докер речь не идёт.
реального эффекта на их работу или работу системы в целом наличие или отсутствие cgroups для этих сервисов — не оказывает
Со временем все системные процессы, я надеюсь, будут переписаны с использованием cgroups для ограничения доступа, со сбросом не нужных для их работы capabilities, с фильтрами syscall'ов и тогда мы получим более надёжную и секьюрную систему «из коробки». Сейчас так обычно не делается, потому что на баше это выливается в десятки строк.
А ещё есть systemd.resource-control — как вы в скрипте ограничите I/O процесу? Или макс. количество тасков в cgroup?
Конечно, всё это делается на баше, но скрипт всё растёт и растёт.
И снова бессмысленная фича, решающая несуществующую проблему. Да, есть начальный этап загрузки
При чём тут загрузка?
systemctl restart foo.target — перезапускает сразу несколько связанных сервисов. Пример из жизни #1: приложение на Python/Django с воркером Celery, код единый, при деплое нужно перезапустить оба сразу.
Пример из жизни #2: мы запускаем oneshot юнит от юзера (с ограничениями ProtectSystem=strict, сброшеные capabilities), но нам надо после того, как он отработал, сразу же автоматически запустить другой oneshot юнит от рута без ограничений. Делается с помощью зависимости After=bar.service. Либо опять городить нечитаемый bash скрипт.
Запускаем systemd-cgls — сразу видна картина, что запущено, для чего. Особенно если зашли на чужой сервер и надо за 60 секунд понять, что там работает. При этом неважно, это Debian, Ubuntu, Centos, RHEL, всё одинаково, все процесы отсортированы по группам. Кто у нас ещё умеет cgroups использовать по полной? runit умеет?
его сумели быстро пропихнуть почти везде, не смотря на сильное сопротивление сообщества
Потому что унифицирует кучу вещей, приводит из в порядок и сближает разные дистрибутивы. А омлет нельзя приготовить, не разбив чьих-то яиц.
основанную на взаимодействии равноправных коллег. При работе в этой системе нет нужды ни в иерархии, ни в консенсусе
,
На аттестации оцениваем результаты сотрудников
Что-то не сходится у вас.
Кроме того, чтобы организация стала «бирюзовой», там хотя бы кто-то должен быть эволюционировавший до этого уровня и транслирующий эти ценности, идеи и смыслы «из первых рук». Иначе получим карго-культ, не более того.
У вас такие есть люди? Их крайне мало и я вживую таких не встречал.
Во внешних клавиатурах Lenovo встроен Trackpoint — и прокрутка, и всё остальное.
Если пойти дальше, то в TypeMatrix ещё и Enter в центр перемещён.
Смещения вообще не должно быть, т.к. оно скорее способствует травмированию. См. TypeMatrix как наиболее традиционно выглядящую. А если радикальные решения подходят, то Maltron или Kinesis Advantage.
Жаль, что в ноутбуки не ставят клавиатуры без смещения, например TypeMatrix вполне бы поместилась.
Это вы привыкли к идее, что функция — это со скобочками. Почитайте про Smalltalk — от него Ruby очень многое почерпнул, станет понятнее, почему можно без скобок жить.
В большинстве случаев возращаемое значение в руби значимо, из этого и стоит исходить.
Вообще никак не нишевой. Он одного класса с Go. Но что сырой, это да, нужно согласиться :(
Если бы Crystal быстрее развивался, то легко бы потеснил Go. Но за Go стоят практически неограниченные ресурсы гугла и легионы разрабов на волне хайпа. У Crystal маленькая команда разработчиков и про него мало кто слышал :(
Я уже сам написал пару мелких проектов на Crystal, но инфраструктура слабая, shard'ов (внешних модулей) мало, комьюнити небольшое. Печально, конечно.
В моём личном сравнении Go vs Crystal последний по удобству выигрывает с отрывом. Именно за счёт рубевого синтаксиса.
Маинтейнеры тоже, бывает, не любят документацию читать. Вообще, это копипаста из дебиана (там тоже
--daemon). По хорошему, надо бы баг зарепортить, конечно.Это сделано для совместимости, чтобы systemd-sysv-generator(8) нормально работал, потому что в случае с sysv init нормальное поведение — это форкающийся демон. Подозреваю, что в будущем эту штуку удалят.
runit никогда не заявлял совместимость с sysv init, равно как не претендовал на его полную замену (хотя в радикальной конфигурации его вроде даже можно как init запускать, размуеется, переписав вначале все скрипты запуска сервисов).
Ничья. Если бы openvpn упал в системе с sysv init его бы никто даже не пытался бы перезапустить.
Потому что «проверенную временем» схему с форком и уходом в background надо безжалостно выпиливать везде где только можно. В случае с openvpn это опция
daemon(её найти и удалить).В вашем случае, скорее всего, openvpn форкался и в таком случае systemd может и не отследить, что сервис упал.
Скрипт не поможет, потому что отсылать должен $MAINPID, иначе будет так:
В случае systemd есть стандартное соглашение по директориям, их функциям и приоритету. См. systemd.unit(5)
Ну да, например в
mongod.serviceуказаноType=forking, однако надо при первой же возможности от форка избавляться. Монга сама умеет в foreground стартовать.А вы, надеюсь, правите не в
/lib/systemd/system? Надо это делать в/etc/systemd/system, а пакетам, в свою очередь, туда лезть не нужно.Например,
systemctl mask some.serviceи делаем свой unit с немного другим именем.С чем конкретно вам бороться нужно было? Вот минимально необходимый unit, чтобы сервис работал (причём, если не надо его запускать после ребута автоматом, то достаточно 2 первые строки):
Вы можете на shell'е написать менее чем в 4 строки скрипт для sysvinit?
Смотря как сдох. Если упал — будет перезапущен. А если процесс подвис, то это не для systemd задача. И кофе в постель он тоже не приносит.
Какие конкретно?
Точно так же, как не разбирались в sysvinit скриптах. Вы их смотрели — там сплошная копипаста и костыли. Люди вообще не любят доки читать, зато транслировать чьи-то там слухи гораздо проще.
Так всё работает и с ним, в чём проблема? В том, что надо ещё десяток man'ов прочитать?
А потом появился myservice3, про него забыли и т.п. И про докер не надо, это уже другой уровень абстракции.
Ничего странного. Это случай из жизни — запускаем
dehydratedдля обновления сертификатов Let's Encrypt. Т.к. ему не нужны особые права, то запускаем от юзера. Потом надо от рута запустить reload сервисов, где сертификаты используются — для этого второй юнит, связанный с первым.sudo? Ну ок, а если хочется ему ограничить права, например так:
Опять же, вспоминаем, что unit не может быть запущен параллельно два раза, что сплошь и рядом встречается при запуске из крона (да, для этого надо ещё костылей городить, проверять pid файлы и т.п.)
Задачи заменить все баш скрипты никогда не ставилось.
А user.slice как вы увидите? Или «это не надо»? Напоминаю, что systemd загоняет все процессы (кроме кернел тредов, конечно же) в какой-то вменяемо названный cgroup.
Про докер речь не идёт.
Со временем все системные процессы, я надеюсь, будут переписаны с использованием cgroups для ограничения доступа, со сбросом не нужных для их работы capabilities, с фильтрами syscall'ов и тогда мы получим более надёжную и секьюрную систему «из коробки». Сейчас так обычно не делается, потому что на баше это выливается в десятки строк.
А ещё есть
systemd.resource-control— как вы в скрипте ограничите I/O процесу? Или макс. количество тасков в cgroup?Конечно, всё это делается на баше, но скрипт всё растёт и растёт.
При чём тут загрузка?
systemctl restart foo.target— перезапускает сразу несколько связанных сервисов. Пример из жизни #1: приложение на Python/Django с воркером Celery, код единый, при деплое нужно перезапустить оба сразу.Пример из жизни #2: мы запускаем oneshot юнит от юзера (с ограничениями
ProtectSystem=strict, сброшеные capabilities), но нам надо после того, как он отработал, сразу же автоматически запустить другой oneshot юнит от рута без ограничений. Делается с помощью зависимостиAfter=bar.service. Либо опять городить нечитаемый bash скрипт.Запускаем
systemd-cgls— сразу видна картина, что запущено, для чего. Особенно если зашли на чужой сервер и надо за 60 секунд понять, что там работает. При этом неважно, это Debian, Ubuntu, Centos, RHEL, всё одинаково, все процесы отсортированы по группам. Кто у нас ещё умеет cgroups использовать по полной? runit умеет?Потому что унифицирует кучу вещей, приводит из в порядок и сближает разные дистрибутивы. А омлет нельзя приготовить, не разбив
чьих-тояиц.,
Что-то не сходится у вас.
Кроме того, чтобы организация стала «бирюзовой», там хотя бы кто-то должен быть эволюционировавший до этого уровня и транслирующий эти ценности, идеи и смыслы «из первых рук». Иначе получим карго-культ, не более того.
У вас такие есть люди? Их крайне мало и я вживую таких не встречал.
А результат сохранился? Ну, т.е. если прекратить приём семакса на полгода-год, например, то позитивные эффекты останутся?
А опыт вы не получили что ли? Это ж самое ценное.
Вы стали круче, а они деградируют и жиреют.
Дешёвая еда это жизненно важно, потому что без неё можно умереть. Всё остальное не особо и нужно.
LTE модем — это спорная вещь, например если ездить за границу, то по диапазонам частот можно не попасть. Или есть уже all-band модели?
Для параноиков — труднее прятать своё местоположение.
Не встречал. Даже американский T-Mobile прекратил таким баловаться, хотя в 2013 году сам напоролся на это.
На Lenovo MiiX 320 есть более-менее подобное. Но это девайс несколько другого класса :)