История изменений

Но что это позволяет сделать такого особенного (что тот же systemd не может)?

systemd - инит-фреймворк, который по задумке автора должен уметь все. вопрос-то не в том, чего не может.

мне это напоминает старую ситуацию с php (условно!). тебе нужно сделать не типовой магазин, а что-то кастомное. и перед тобой стоит выбор: 1) писать на чистом php с нуля долго и нудно или 2) опять же долго и нудно изучать какой-то фреймворк, чтобы убить кучу времени и в итоге выяснить, что а) он в 2-3 раза более жирный по памяти, чем решение 1 и б) его готовый функционал тебе чем-то не подходит и надо что-то всеравно делать по пути 1.

«мелкие кубики» (unix-way) все-таки быстрее, чем путь 1, и в то же время их проще освоить и заменить (если не подходит), чем большой кубик на пути 2.

Но что это позволяет сделать такого особенного (что тот же systemd не может)?

systemd - инит-фреймворк, который по задумке автора должен уметь все. вопрос-то не в том, чего не может.

мне это напоминает старую ситуацию с php (условно!). тебе нужно сделать не типовой магазин, а что-то кастомное. и перед тобой стоит выбор: 1) писать на чистом php с нуля долго и нудно или 2) опять же долго и нудно изучать какой-то фреймворк, чтобы убить кучу времени и в итоге выяснить, что а) он в 2-3 раза более жирный по памяти, чем решение 1 и б) его готовый функционал тебе чем-то не подходит и надо что-то всеравно делать по пути 1.

«мелкие кубики» (unix-way) все-таки быстрее, чем путь 1, и в то же время их проще освоить и выкинуть, чем большой кубик на пути 2.

Но что это позволяет сделать такого особенного (что тот же systemd не может)?

systemd - инит-фреймворк, который по задумке автора, должен уметь все. вопрос-то не в том, чего не может.

мне это напоминает старую ситуацию с php (условно!). тебе нужно сделать не типовой магазин, а что-то кастомное. и перед тобой стоит выбор: 1) писать на чистом php с нуля долго и нудно или 2) опять же долго и нудно изучать какой-то фреймворк, чтобы убить кучу времени и в итоге выяснить, что а) он в 2-3 раза более жирный по памяти, чем решение 1 и б) его готовый функционал тебе чем-то не подходит и надо что-то всеравно делать по пути 1.

«мелкие кубики» (unix-way) все-таки быстрее, чем путь 1, и в то же время их проще освоить и выкинуть, чем большой кубик на пути 2.