Comments 20
Кажется, этот его подход — на каждый чих своя утилита — в итоге и привел к тому, что сообщество выбрало другие решения.
так-то это идеология UNIX на те-же архиваторы посмотри, tar обьединяет фалы в архив, bz2 сжимает архив.
Запаковать тоже можно одной командой. tar -cjfv file.tar.bz2 file… Но при этом все равно работает связка tar + bzip2. Думаю, что worldxaker это имел в виду.
У tar изначально вообще другое предназначение было, никакого сжатия там не подразумевалось.
По большому счету сжатия у tar и сейчас нет. Все сжатие ( -z, -Z, -j… -I ) осуществляется подключаемыми внешними фильтрами. Сам по себе tar компрессией не занимается.
Было интересно. спасибо
в логировании видимо опечатка: cd log && mkdir mail
main?
Можно сколько угодно твердить мантру про философию UNIX, но правда в том, что _простые_ запускалки стартовых скриптов на самом деле не решают проблему инициализации и управления сервисами.

Нужно знать взаимные зависимости сервисов (чтобы при загрузке запускать их параллельно), неплохо бы воспользоваться всеми ништяками cgroups и т.д. Например, простейшая, казалось бы, задача — по PID процесса узнать, какой сервис за него отвечает — не решается нигде, кроме как в systemd. Так что как бы не говнили systemd за переусложненность, архитектурные проблемы и чего там еще, его появление — это _очень_ большое дело (и, безусловно, хорошее) для развития всей платформы.
> Например, простейшая, казалось бы, задача — по PID процесса узнать, какой сервис за него отвечает — не решается нигде, кроме как в systemd.

Либо двумя строчками башскрипта. Взять полученный pid и записать его в файл.
К сожалению, все не так просто и для SysV однозначного решения нет. Не все сервисы утруждают себя созданием PID-файлов, кроме того, очевидно, что у сервиса может быть больше чем один процесс. Да и вообще, PID-файлы решают обратную задачу — по имени сервиса найти процесс, а не наоборот. В общем, итоговое решение у меня заняло строчек двести, с использованием различных угадаек. В systemd же это решается тривиально, так как каждый сервис запускается в своей cgroup.

Философия или принципы Unix — это не мантра, а стратегия разработки ПО, которая по сей день актуальна. В этом отличие от мантры, которую повторяют, но ничего не делают или делают наоборот.


Как мне кажется многие обиды и непонимание возникли оттого, что стратегию стали разменивать ради тактических соображений. Именно это и означает отказ от принципов Unix, ради того, чтобы инит умел находить сервис по PID и стартовал ОС на 17% быстрее.


Параллельный запуск процессов уже многие иниты умеют (nosh, openRC, runit), также как и отслеживать зависимости. OpenRC имеет поддержку cgroups.

Параллельный запуск процессов уже многие иниты умеют (nosh, openRC, runit), также как и отслеживать зависимости.

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


OpenRC имеет поддержку cgroups.

Которая там была чисто для галочки "поддерживает cgroups". Возсожно сейчас что-то изменилось, но тогда это была профанация.

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

Revision as of 06:36, 22 June 2013 by

К моменту голосования чего именно: инит системы Debian?

Да, извиняюсь, забыл указать. Изменения в этой части openrc очень удачно «совпали» с подготовкой к голосованию, емнип

> openRC

Официально не поддерживает параллельный запуск. Эта фича является сильно экспериментальной. Некоторые сервисы не способы стартовать или остановиться корректно, и это отражено в багтрекере. Проблема так и не решена, вместо этого стоит пометка «а мы и не обещали вам, что всё будет работать».
Only those users with full accounts are able to leave comments. Log in, please.