заказчика которому нужна программа которая работает потом, но зато везде, даже там где ему не нужно

И кто заказчик в опенсорсе?

Скажу, что это плохо, но не критично, поскольку всегда можно держать несколько версий библиотек или вовсе статически слинковаться.
Ядро ты не слинкуешь.

Отличный совет, очень пригодится ребятам в детском саду. Того же уровня примерно глубина мысли. Готов за свой счет оплатить портирование-то?

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

либо фичу можно реализовать на пользовательском уровне, но менее эффективно

This. И зачем нам такое счастье? Здесь я очень хорошо понимаю авторов systemd. Нет смысла лепить костыли; это первоочерёдная задача ядра — обеспечивать работу прикладных программ и выступать арбитром по ряду вопросов.

This. И зачем нам такое счастье?

Зависит от пользовательской базы. Если твоя фича в ядре есть на паре систем, то никто делать её поддержку не будет. Да и как показывает практика, никакого rocket science в ядре нет, поэтому обычно сделать фичу в юзерспейс не стоит больших усилий.

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

Почему сразу костыли?

Не, ну а как ты сделаешь {i,d,fa}notify какой-нибудь? Не rocket science ни разу, но в юзерспейсе это поллинг (== костыль). Или пресловутые контрольные группы — хотя бы просто как группы процессов, без управления ресурсами.

Не, ну а как ты сделаешь {i,d,fa}notify какой-нибудь?

Во-первых, аналоги этого механизма есть во многих ОСях, в том числе во фряхе и в винде. Во-вторых, это реализуется перечитыванием директории и я это делал.

Не rocket science ни разу, но в юзерспейсе это поллинг (== костыль).

С чего бы это? Нормальное решение.

Или пресловутые контрольные группы — хотя бы просто как группы процессов, без управления ресурсами.

Зависит от задачи.

fanotify

С чего бы это? Нормальное решение.

Ну я убеждён в том, что это не «нормальное решение». Если на десятке-другом путей не будет заметно даже на микроволновке, то на тысяче-другой (а где-нибудь рано или поздно такой юзкейс возникнет) — «нормальное решение» перестанет быть нормальным. В общем, асимптотика. Поэтому костыль.

Да и вопрос скорее принципиальный. С чего бы юзерспейс должен костылить то, что правильнее сделать в ядре?

Слежение за целой fs? Ну в винде есть такое.

У inotify ровно те же проблемы, просто нужно либо чуть больше директорий либо очень много событий чтобы всё загнулось. Если возникает необходимость отслеживать тысячи директорий, то надо ответить на вопрос зачем? Тут даже уровень ядра не поможет. Кстати, у inotify есть побочные эффекты — он дескрипторы не переиспользует и использует цифровой поиск по ним — при большом аптайме приложение с inotify будет тормозит и «костыль»-поллинг будет эффективней.

systemd можно сравнить с ядром Linux

У Linux упоротые разработчики, огроменные тонны говнокода без контроля качества, сборки, нелепейшие баги и ошибки, дефективность архитектуры? Ах нет? Ок, следующий!

всё больше софта не следует стандартам POSIX, становится linux-зависимым (напрямую или посредственно через библиотеки и утилиты)

Среди прикладного и околоприкладного это не наблюдается (если не считать привязку к systemd).

Stahl> Это, кстати, одна из причин почему винда такая живучая — они тянут с собой груз совместимости за ого-го сколько лет.

4.2

Груз совместимости не дольше двух мажорных версий.

Переведи это в годы. Не ого-го?

Не надо передёргивать. Есть два подхода, которые могут работать в реальности: наговнокодить софтину быстро и грязно без «лишнего» тесирования и написать грамотно продукт, который будет делать то, что нужно, и не иметь архитектурных проблем для быстрой доработки под изменяющиеся требования. Второй вариант требует от заказчика некоторого терпения и разума, но окупается уже в ближайшей перспективе.

deep-purple> И кто заказчик в опенсорсе?

Три варианта в зависимости от проекта:

1. Тот, кто платит.

2. Сам разработчик.

3. Сообщество.

В случае с systemd заказчиком является RedHat.

Что ты скажешь о программе, которая работает только на RH 6 с ядрами 2.6.32-279 или 2.6.32-358? Данные взяты не из головы, из доки.

Stahl> Переведи это в годы. Не ого-го?

В линуксе не хуже с этим обстоят дела. См. LSB. А ещё старые вендовые программы линукс лучше может запускать за счёт WINE.

А это уже говнокод. Такого и на венде полно.

Думаю, что это программа уже нахрен никому не нужна, раз её не портировали на более свежие выпуски.

Вайн? Да брось ты. Эта штука работает через раз. Или через два. Может, конечно, что-то и изменилось в лучшую сторону: я последний раз это недоразумение тыкал во времена ~1.0 версии.

++

Смеялись всем отделом. Так и вижу заказчика которому нужна программа которая работает потом, но зато везде, даже там где ему не нужно.

YAGNI

А это вполне себе последняя версия телеги под названием Symantec Storage Foundation.

На самом деле, более свежие ядра поддерживаются, но только для SLES. Теоретически, можно завести, но (а) я не пробовал, (б) поддержки вендора у тебя уже не будет.

Stahl> Вайн? Да брось ты. Эта штука работает через раз. Или через два.

4.2

Сам пользуюсь для сравнительно старых игр. Становится только лучше.

Ну я и говорю, что не нужно — было бы нужно, то уже портировали бы.

Symantec

Да уж... А ведь были времена когда это название не вызывало отвращения...

А тем не менее, относительно активно используется (пруфов не будет, это со слов продаванов, которые его торгуют).

Ну я и говорю, что не нужно — было бы нужно, то уже портировали бы.

ННП. Что и куда портировали?

Да уж... А ведь были времена когда это название не вызывало отвращения...

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

Ещё бы сказанул, что софт привязывается к РС, а UltraSPARC игнорируется.