История изменений
Исправление intelfx, (текущая версия) :
«Не укладываться» оно может по разным причинам же.
Например, если вместо ANSI С-совместимой frobnicate() используется какая-нибудь glibc-специфическая (или хуже) frobnicate2(), отличающаяся порядком параметров, — тогда да, бить по рукам нужно автора (т. к. не было никаких причин использовать нестандартный вариант).
Но в случае systemd использование ряда Linux-специфичных API, насколько понимаю, оправдано.
Взять fanotify(7) — первое, что пришло в голову. Позиция POSIX-пуристов выглядит так: «стандартным компонентам не нужно отслеживать изменения в файлах!один-один».
Или цгруппы. Отказываться от столь удобного инструмента управления иерархиями процессов в пользу бешеных танцев с /proc и нетлинком — ИМХО, глупо.
Особенно если учесть, что под вопросом стоит переносимость не на 50% систем, а на своего рода маргинальщину.
Исправление intelfx, :
«Не укладываться» оно может по разным причинам же.
Например, если вместо ANSI С-совместимой frobnicate() используется какая-нибудь glibc-специфическая (или хуже) frobnicate2(), отличающаяся порядком параметров, — тогда да, бить по рукам нужно автора (т. к. не было никаких причин использовать нестандартный вариант).
Но в случае systemd использование ряда Linux-специфичных API, насколько понимаю, оправдано.
Взять fanotify(7) — первое, что пришло в голову. Позиция POSIX-пуристов выглядит так: «стандартным компонентам не нужно отслеживать изменения в файлах!один-один».
Или цгруппы. Отказываться от столь удобного инструмента управления иерархиями процессов в пользу бешеных танцев с /proc — ИМХО, глупо.
Особенно если учесть, что под вопросом стоит переносимость не на 50% систем, а на своего рода маргинальщину.
Исходная версия intelfx, :
«Не укладываться» оно может по разным причинам же. Если вместо ANSI С-совместимой frobnicate() используется какая-нибудь glibc-специфическая (или хуже) frobnicate2(), отличающаяся порядком параметров, — тогда да, бить по рукам нужно автора (т. к. не было никаких причин использовать нестандартный вариант). Но в случае systemd использование ряда Linux-специфичных API, насколько понимаю, оправдано.
Например, взять fanotify(7) — первое, что пришло в голову. Позиция POSIX-пуристов выглядит так: «стандартным компонентам не нужно отслеживать изменения в файлах!один-один».
Или цгруппы. Отказываться от столь удобного инструмента управления иерархиями процессов в пользу бешеных танцев с /proc — ИМХО, глупо.
Особенно — если учесть, что под вопросом стоит переносимость не на 50% систем, а на своего рода маргинальщину.