Половина технического комитета debian выступила за systemd

Upstart-конфиги должны находиться не в пакете с апстартом, а в пакете каждого сервиса свой конфиг (как и скрипты в /etc/init.d/). Но на upstart действительно не всё портировали, но это не проблема, sysv там эмулируется. Вот список upstart конфигов что у меня есть.

Что ж, значит, я ошибся. Признаю свою оплошность. Глянул apache2, postgresql-common - не нашёл, а веб-интерфейс поиска пакетов не позволяет искать по началу пути.

Рекурсивно?

нет, но этого достаточно для создания каталогов 0777.

А nosuid придумали дураки

nosuid придумали совсем для другого. Если юзер хочет запустить говно на своём компьютере, то не нужно ему мешать. Ему виднее. Nosuid нужен для каталогов, в которых в принципе не может быть исполняемых файлов, вроде /tmp/ на сервере.

А вот вспомнить некоторые особенности нагромождения костылей в линуксах, когда видишь их чаще на сервере, чем на десктопе — полезно.

все эти «костыли» — исключительно твоё рукожопие. И не более того.

Ну ладно, не только твоё. Но всё равно рукожопие, лень и тупость.

И если кто-то напейсал [ "x$a" -eq "x$b" ] то проблема совсем не в баше, а в руках.

Ну и зачем мне ФС с правами, если всё равно приходится создавать всё с 0777/0666?

А флешки без nosuid юзерам разрешать нельзя, иначе они получат рута.

Ты говоришь это DrBatty? Серьёзно? И у тебя пять звёзд? Он же принципиально умеет только говорить, разбираться — это для лохов.

Не каждый [ проглотит

а при чём тут вообще команда test(1)? Ты хотел сравнить в bash'е два целых числа? Ну сравни, в чём проблема, и при чём тут [?

Да, это будет при a=" или b=".

а при чём тут ЯП? Говнокод можно писать на любом ЯП, если мануал не читать как ты.

а при чём тут ЯП? Говнокод можно писать на любом ЯП, если мануал не читать как ты.

Ну я и говорю: твой говнокод вылетит из скрипта с ошибкой при определённых $a или $b.

И да, bash есть не везде, а в ash нет ((.

Ну и зачем мне ФС с правами, если всё равно приходится создавать всё с 0777/0666?

ну например ты можешь создать временный файл который никто кроме тебя не тронет с правами 0600. Или ты можешь создать файл с правами 0644, который только ты можешь менять, а все остальные только читать. Естественно эти права работают только пока флешка рядом с тобой, в комп воткнута. Если её вынуть — увы. Но это к любым системам прав относится, не только к флешкам и не только в *nix.

Просто не нужно ждать чуда. Естественно, если у тебя выкрали флешку с не зашифрованными файлами, то глупо ждать, что вора остановят права. Не могут, и не должны.

Ну я и говорю: твой говнокод вылетит из скрипта с ошибкой при определённых $a или $b.

GIGO. Ты пытаешься сравнить нечисла как числа. С пустой строкой это прокатывает лишь потому, что пустая строка это «ничто», NIL.

И да, bash есть не везде

разговор был за bash. Ты ещё command.com вспомни, и чего там нет.

Чем те же люди в Убунте тебя не устроили?

Добавляют десяток специфичных багов, из-за которых некоторые (которые внезапно узнали на чем базируется изделие №1) потом боятся ставить Дебиан Тестинг, ожидая в нем аналогичных багов.

Это в свою очередь портит репутацию Дебиана.

Вот как будет известно, тогда и приходи.

Будет нелишним предупредить.

В скриптах можно городить любые извращенские костыли. Это линуксвей. А конфиги сильно ограничивают в возможностях.

Никто не запрещает написать скрипт и запускать его как сервис. Разница между sysvinit и systemd/upstart в том, что в первом городить костыли приходится в каждом случае, а во вторых - только при насущной необходимости (что бывает нечасто).

А чем принципиально отличается парсинг конфигов от выполнения скриптов?

Тем, что в скриптах необходимо самому разруливать гонки, конфликты PID-файлов, следить за состоянием, зависимостями... А если скрипты ещё и запускаются параллельно, как в Debian... Костыль start-stop-daemon как раз и был создан, чтобы убрать часть этих задач в отдельную сущность, но так всё равно не решить все проблемы.

Вообще, сам факт конфиг == программа - идиотизм.

А как прикажете справляться с обновлениями, если скрипт был вами модифицирован? В Debian пришлось для этого городить /etc/default/.

Немного цитат из багрепорта:

Either upstart or systemd configurations are *radically better* than init scripts on basically every axis. They're more robust, more maintainable, easier for the local administrator to fix and revise, better on package upgrades, support new capabilities, etc.

I think it's painfully obvious if you compare an init script to an upstart or systemd configuration file for a simple daemon like, say, my lbcd package.

For those who don't agree, please try the exercise of writing systemd and upstart configuration files for some typical daemon package and look at the number of lines of code in both and the behavior in edge cases (daemon already running, daemon running but with no PID file because something else deleted it, daemon part of a dependency chain that shouldn't fire until the daemon is actually listening to the network, correct exit status for various failure conditions, stopping the daemon when there is a user process with the same name as the daemon also running, and the other cases Policy says one must handle). Now compare the length of time it took you to make an init script correctly handle all those cases versus how long it took to write the upstart or systemd configuration. (Note that I have found, IIRC, two different edge-case bugs in /etc/init.d/skeleton while working on Debian, so even if you start from that file, which is only applicable to a relatively narrow range of circumstances, you can still fail edge cases.)

No, System V Init scripts are not ideal on the long-term outcome since they are highly distribution-specific, error-prone and annoying to maintain. We have had tons of bugs in the bug tracker because of broken init scripts, like this one http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=668890.

I don't understand why anyone would think that having to write a small piece of code to start another program is a sensible and good design, especially when this is done for dozens of programs (= daemons) in very much the same way. It absolutely makes sense to encode the logic to start and control a daemon through a single piece of C code rather than writing more-or-less the same bash script for every single daemon on your machine.

тупо и жадно

И ещё высокомерно. Это я про дебиановцев.

Да это свидетели поттеринга пугают каким-то там соглашением которое создатель линукс мент подписал. Оно вообще тут никаким боком.

городить любые извращенские костыли. Это линуксвей.

//добавил в фортунки.

А как прикажете справляться с обновлениями, если скрипт был вами модифицирован? В Debian пришлось для этого городить /etc/default/.

Когда я модифицирую init скрипт или конфиг upstart (ну бывает, заменю что нибудь, например некоторое ПО запрещаю запускаться на отличных от 2 ранлевелах или некоторые демоны вовсе запрещаю запускаться (в upstart прописываю параметр manual) (cups, например, мне не нужен, но он притянут зависимостями)), при обновлении ко мне пакетный менеджер постоянно пристаёт с вопросами что делать с отредактированными скриптами и конфигами, заменить на новый или оставить старый (также предлагает посмотреть diff). Если оставить старый (я обычно выбираю это), он рядом положит новый, я потом могу посмотреть diff и если там есть какие-то нужные изменения, я их переношу в свой, не затерев свои кастомайзинги. А что, с systemd что-то упростится?

(Firestarter)

Никто не запрещает написать скрипт и запускать его как сервис. Разница между sysvinit и systemd/upstart в том, что в первом городить костыли приходится в каждом случае, а во вторых - только при насущной необходимости (что бывает нечасто).

4.2

ты «забыл» про то, что типичные скрипты УЖЕ есть. Т.ч. не нужно ничего «городить». Надо просто изучить shell.

А неосиляторы типа x3al будут страдать в любом случае.

Тем, что в скриптах необходимо самому разруливать гонки, конфликты PID-файлов, следить за состоянием, зависимостями... А если скрипты ещё и запускаются параллельно, как в Debian...

снова 4.2

конфликты уже разрулены. А параллельная загрузка везде. Даже в Slackware Linux.

Костыль start-stop-daemon как раз и был создан, чтобы убрать часть этих задач в отдельную сущность, но так всё равно не решить все проблемы.

этот костыль годен для управления Over9000 серверов сразу. В слаке его нету (по дефолту). Проблемы, которые нужно решить, этот костыль решает вполне.

Вообще, сам факт конфиг == программа - идиотизм.

это твоё мнение. Но факт в том, что со временем любой конфиг превращается в программу. Т.ч. лучше будет сделать это by design, а не потом, костылить программу в конфиг.

А как прикажете справляться с обновлениями, если скрипт был вами модифицирован? В Debian пришлось для этого городить /etc/default/.

проблема обновления/хранения исходных кодов давно исследована и решена.

А что, с systemd что-то упростится?

Да. Поставляемые с пакетами сервисные файлы лежат в /lib/systemd/system/ и не предназначены для редактирования; пользователи же могут как полностью переопределять сервисные файлы, положив файл с таким же именем в /etc/systemd/system/, так и переопределять конкретные директивы, создавая файлы .conf в /etc/systemd/system/servicename.service.d/ лишь с нужными директивами.

Например, если вы хотите переопределить лишь директиву ExecStart, вы кладёте в указанный каталог файл с ExecStart=ваша_команда. Легко и просто, и вполне в духе универсального правила «/etc overrides (/usr)/lib», которому также следуют dbus, policykit, udev, x-сервер (xorg.conf.d/) и многие-многие другие. Причём в systemd есть специальная утилита systemd-delta, которая позволяет удобно вести учёт и просматривать переопределённые директивы.

А если вы хотите лишь временно переопределить какие-нибудь директивы или полностью сервисный файл, можно точно так же положить свой в /run/systemd/system, который по приоритету выше /lib, но ниже /etc; тогда изменения пропадут после перезагрузки.

Тот же механизм переопределения действует и для tmpfiles.d, *.target.wants и так далее. Очень простой и гибкий механизм.

А ещё можно включать в файлы другие файлы с помощью .include, вынося общие для нескольких сервисов параметры в отдельный файл. Модифицируя последний, можно управлять параметрами сразу нескольких сервисов.

Серьёзно, почитайте наконец про systemd. Тогда поймёте, почему на него так массово переходят дистрибутивы, и почему подавляющее большинство выливаемых на него помоев не соответствуют действительности.

например некоторое ПО запрещаю запускаться на отличных от 2 ранлевелах или некоторые демоны вовсе запрещаю запускаться

Для таких простых задач в systemd вообще нет нужды лезть в конфиги: # systemctl disable service отключает автоматический запуск сервиса при старте системы, но при этом его всё ещё можно запустить вручную; # systemctl mask service полностью запрещает запуск сервиса, что автоматически, что вручную.

При этом всё это можно проделать и манипуляциями с символьными ссылками вручную, если так хочется.

Для таких простых задач в systemd вообще нет нужды лезть в конфиги: # systemctl disable service отключает автоматический запуск сервиса при старте системы, но при этом его всё ещё можно запустить вручную; # systemctl mask service полностью запрещает запуск сервиса, что автоматически, что вручную.

При этом всё это можно проделать и манипуляциями с символьными ссылками вручную, если так хочется.

Ну тут ничего революционного, то же самое с sysvinit: update-rc.d или ручное редактирование симлинков.

(Firestarter)

Серьёзно, почитайте наконец про systemd.

Не хочу. Уже твой комментарий говорит что он ужасен. Нагородили хрен пойми чего. Слишком сложно. Где KISS?

Тогда поймёте, почему на него так массово переходят дистрибутивы,

Не показатель. Вендой тоже пользуется гораздо больше народу и что?

(Firestarter)

Нагородили хрен пойми чего. Слишком сложно. Где KISS?

Пипец. Сложно. Написать одну строчку.

Это ж не то что выучить bash и модифицировать скрипты, после чего трахаться при обновлениях, вручную разрешая конфликты параметров. Вот это просто!

Не показатель. Вендой тоже пользуется гораздо больше народу и что?

То, что она полностью устраивает большинство народа. Неожиданный вывод, правда?

А уж в контексте upstart говорить про KISS с его event'ами и блокировкой состояния до и сбрасыванием после запуска сервиса... Это нужно обладать весьма необычным складом ума, чтобы вместо пары объект-связь (как и работает человеческий мозг, между прочим) простой считать модель объект-событие.

Ну тут ничего революционного, то же самое с sysvinit: update-rc.d или ручное редактирование симлинков.

Ну расскажите ещё пользователю Debian про sysvinit и update-rc.d, а то я не в курсе совсем.

А потом расскажите, как сделать, чтобы остановленные сервисы не запускались при обновлении, но чтобы их можно было запустить вручную, а также чтобы сервис, отключённый с помощью update-rc.d service disable, но запущенный вручную, корректно завершался при выключении/перезагрузке.

Вы, видимо, просто не в курсе, какие хаки приходилось применять, чтобы заставить всю эту мешанину скриптов более-менее нормально работать, сколько sleep'ов в них понавешано с комментами типа «вроде на глазок должно хватить», и сколько багрепортов отправлено в случаях, когда не хватает.

сколько sleep'ов в них понавешано с комментами типа «вроде на глазок должно хватить», и сколько багрепортов отправлено в случаях, когда не хватает.

$ cd /etc/init.d
$ grep sleep * | wc -l
37
$ grep -l sleep * | wc -l
23
$ ls -l | wc -l
77

Ужас-ужас.

Слишком сложно.

Может, всё же объясните, что именно вам показалось слишком сложным?

И сколько же тебе платят за такие портянки текста, а главное что/кто дает мотивацию (не мотивировку, черт возьми) на написание оных?

Ужас-ужас.

Он самый.

Некоторые другие проблемы перечислены в процитированных комментариях здесь, а также в http://bugs.debian.org/727708.

И сколько же тебе платят за такие портянки текста

Дети эпохи Интернета не могут прочесть больше одного абзаца?

а главное что/кто дает мотивацию (не мотивировку, черт возьми) на написание оных?

«В Интернете кто-то неправ».

Человек спросил. Я ответил. Не дойдёт до него, так кому-нибудь другому пригодится.

То, что она полностью устраивает большинство народа.

А это потому, что проще и приемлимей для большинства ничего нет. Вот и юзают они твою венду, кто-то смирившись, а кто-то «через немогу но надо».

Дети эпохи Интернета не могут прочесть больше одного абзаца?

Опять ты ничего не понял. Зачем ты пишешь это хейтерам? Я не вижу в этом логики, а ты?

Половина технического комитета debian выступила за systemd

...и порвала пукан половине лоровцев.

Опять ты ничего не понял. Зачем ты пишешь это хейтерам? Я не вижу в этом логики, а ты?

А, в этом смысле... Тогда приношу вам свои извинения.

Дело в том, что я не пишу это только хэйтерам. В личной переписке я бы и не стал начинать, но в публичном пространстве есть шанс, что это прочитают здравомыслящие люди, которые просто не знают, как всё обстоит на самом деле. И, может, тоже будут ненавидеть - в конце концов, у всех разные представления «о прекрасном» - но хотя бы обоснованно :).

Не дойдёт до него, так кому-нибудь другому пригодится.

Я не тот человек, но мне пригодилось. Благодарю.

Некоторые другие проблемы перечислены в процитированных комментариях здесь

Эту дешевую демагогию я уже читал у поцеринга.

а также в http://bugs.debian.org/727708.

Начал читать. Дочитал до:

«This bug can be considered fixed upstream: http://cgit.freedesktop.org/systemd/systemd/commit/?id=e3e0314b56012f7

I doubt that anyone would want to port it to systemd <= 208, because in the porting to libsystemd-bus has been completely rewritten from earlier versions».

Перестал читать.

Эту дешевую демагогию я уже читал у поцеринга.

Во-первых, это цитаты не Поттеринга, а весьма и весьма опытных разработчиков Debian.

Во-вторых, называть что-то демагогией, не приводя аргументов - значит умножить ценность своего мнения на нуль.

Есть еще один вариант. Оставить все как есть и взять MATE. Кстати, на мой вкус вполне годный получился бы вариант.

P. S. ох нифига себе тут нафлудили за день.

Начал читать. Дочитал до:

«This bug can be considered fixed upstream: http://cgit.freedesktop.org/systemd/systemd/commit/?id=e3e0314b56012f7

I doubt that anyone would want to port it to systemd <= 208, because in the porting to libsystemd-bus has been completely rewritten from earlier versions».

Перестал читать.

Начал читать про проблемы init-скриптов, а закончил из-за коммита в systemd. Чудеса.

Не читал тред, ибо...
Почему бы (если уж совсем бежать на systemd) не выкинуть нахрен upstart и rc init?
Задолбали уже эти хвосты тянуть. Сделали бы что-то совместимое с не совместимым.

Эту дешевую демагогию я уже читал у поцеринга.

Во-первых, это цитаты не Поттеринга, а весьма и весьма опытных разработчиков Debian.

Вот цитата опытного разработчика Debian:

«It bothers me on some philosophical level that so much functionality that I'd like to keep conceptually separate from an init system is being pulled in to the systemd upstream. And as someone who has spent much of my professional career working with non-x86 systems and who has worked with many non-Linux kernels in different contexts, I've found the anti-portability rhetoric from Lennart, et al, particularly grating.

But a long time ago, in a rec.crafts.metalworking post about teachers, a fellow named Fitch Williams wrote that „in any endeavour it is a fact that you have to succeed with the people who are willing to participate.“»

Во-вторых, называть что-то демагогией, не приводя аргументов - значит умножить ценность своего мнения на нуль.

Меня редко волнует, во сколько оценивается мое мнение. Авторы демагогии по твоей ссылке не особо трудились ее обосновывать.

anti-portability rhetoric from Lennart

Это о чём?

Начал читать про проблемы init-скриптов,

Это тред о выборе новой init-системы, вообще-то. Ты сам читал то, на что ссылку даешь?

а закончил из-за коммита в systemd.

«libsystemd-bus has been completely rewritten from earlier versions». Фразу «completely rewritten» нужно переводить? то, что это случилось после 208 версии - надо объяснять? То, что это случайно совпало с тем, что в RHEL пошла версия 207 - надоо указывать? «Коммит в systemd», ага.

Чудеса.

Чудеса - это то, что с systemd творится.

Вот цитата опытного разработчика Debian

Тот же разработчик, абзацем выше:

It's now clear to me that systemd is technically superior as an init system to upstart. I find the dependency approach easier to think about and work with, unit files seem quite easy to craft and read, I like the status reporting and logging tools, and I find myself agreeing more with Russ that with Ian about the best way to augment daemons that might benefit from it with a readiness protocol.

И в конце данного сообщения:

So, to summarize, I think systemd should be our choice for a new default init system for Debian GNU/Linux.

Отличный аргумент против systemd... OH WAIT

anti-portability rhetoric from Lennart

Это о чём?

https://lists.debian.org/debian-ctte/2014/01/msg00049.html

Отличный аргумент против systemd... OH WAIT

Что oh wait? Да, я читал, что Bdale Garbee - за systemd. Только он не вещает о том, как неправильно писать конфиги на шелле.

Это тред о выборе новой init-системы, вообще-то. Ты сам читал то, на что ссылку даешь?

У вас, похоже, плохо с кратковременной памятью. Цитирую своё сообщение, на которое вы отвечали:

Некоторые другие проблемы перечислены в процитированных комментариях здесь, а также в http://bugs.debian.org/727708.

- и всё это в ветке про проблемы init-скриптов, что несложно проследить, пощёлкав по ссылкам «Ответ на:».

Что oh wait? Да, я читал, что Bdale Garbee - за systemd. Только он не вещает о том, как неправильно писать конфиги на шелле.

Тогда зачем вы привели данную цитату в ответ на сообщение о проблемах со скриптами на шелле?

У вас, похоже, плохо с кратковременной памятью.

Вы, похоже, хорошо умеете валить с больной головы на здоровую.

и всё это в ветке про проблемы init-скриптов

«I believe that sysvinit allows for the most flexibility for users and porters».

«So I believe that, if we need to choose a default right now, it must be sysvinit, and this must be a reliable outcome, i.e. we commit to this and don’t arbitrarily change our mind later».

Да, обсуждение проблем инитскриптов.

Тогда зачем вы привели данную цитату в ответ на сообщение о проблемах со скриптами на шелле?

И эти люди ищут у других проблемы с кратковременной памятью. Ты хоть бы почитал, на что я ответил - там отквочено.

Меня именно anti-portability rhetoric интересует, есть линк?

Меня именно anti-portability rhetoric интересует, есть линк?

Я читал только то, что было на 0pointer, но у Комитета могут быть свои источники.

«I believe that sysvinit allows for the most flexibility for users and porters».

«So I believe that, if we need to choose a default right now, it must be sysvinit, and this must be a reliable outcome, i.e. we commit to this and don’t arbitrarily change our mind later».

Это сообщение не Bdale Garbee, а вообще другого человека Thorsten Glaser, который является разработчиком MirBSD и к Debian не относится.

Ваши передёргивания столь примитивны, что даже неловко как-то.

Ты хоть бы почитал, на что я ответил - там отквочено.

Отквочена часть моего сообщения из ветки про проблемы init-скриптов. На это сообщение вы ответили цитатой Bdale Garbee, но потом сами же сказали, что он не говорит ничего про проблемы init-скриптов.

Чем дольше вы будете юлить, тем глупее будете выглядеть.

который является разработчиком MirBSD и к Debian не относится.

*к техническому комитету Debian