История изменений
Исправление dimgel, (текущая версия) :
У сокета от файла – только путь, на диске он не хранится. Путь (имя) нужен только чтобы два процесса смогли найти общий канал передачи данных. Тогда уж «всё есть файл» надо переформулировать «всё адресуется как файл».
Пример ТСа с докбаром был бы хорош, будь он релевантен. Там персистентная конфигурация, и добавление файлов в условный config.d во всех смыслах проще, удобнее и надёжнее, чем правка общего конфига. И для людей, и для пакетных менеджеров. Поэтому для конфигов в линуксе используется повсеместно:
# find /etc -name '*.d' -type d 2>/dev/null | wc -l
112
[a1 ~]# find /etc -name '*.d' -type d 2>/dev/null | grep -vF /etc/s6 | wc -l
57
(И это я ещё не вспомнил про /usr/share/applications, ~/.idesktop, и наверняка про многое другое.) Но это не значит, что эту идею надо присобачивать повсюду.
Даже по поводу /proc есть у меня сомнения, не шило ли это на мыло: добавить файл (linux-way) vs добавить системный вызов или поле в структуре (windows-way). Вызовы-то побыстрее будут: один syscall против трёх: open + read/write + close. Разве что в /proc можно сделать иерархию каталогов, а в сях (в отличие от плюсей) нету namespaces, ну дык это претензия к сям. Получается, отсутствие в языке средств структурирования имён как фактор выбора неэффективного решения. Ещё и числа все в текстовом виде передаются…
Гы, а почему чел с ником windows10 топит за linux-way?
Исправление dimgel, :
У сокета от файла – только путь, на диске он не хранится. Путь (имя) нужен только чтобы два процесса смогли найти общий канал передачи данных. Тогда уж «всё есть файл» надо переформулировать «всё адресуется как файл».
Пример ТСа с докбаром был бы хорош, будь он релевантен. Там персистентная конфигурация, и добавление файлов в условный config.d во всех смыслах проще, удобнее и надёжнее, чем правка общего конфига. И для людей, и для пакетных менеджеров. Поэтому для конфигов в линуксе используется повсеместно:
# find /etc -name '*.d' -type d 2>/dev/null | wc -l
112
[a1 ~]# find /etc -name '*.d' -type d 2>/dev/null | grep -vF /etc/s6 | wc -l
57
(И это я ещё не вспомнил про /usr/share/applications, ~/.idesktop, и наверняка про многое другое.) Но это не значит, что эту идею надо присобачивать повсюду.
Даже по поводу /proc есть у меня сомнения, не шило ли это на мыло: добавить файл (linux-way) vs добавить системный вызов или поле в структуре (windows-way). Вызовы-то побыстрее будут: один syscall против трёх: open + read/write + close. Разве что в /proc можно сделать иерархию каталогов, а в сях (в отличие от плюсей) нету namespaces, ну дык это претензия к сям. Получается, отсутствие в языке средств структурирования имён как фактор выбора неэффективного решения.
Гы, а почему чел с ником windows10 топит за linux-way?
Исходная версия dimgel, :
У сокета от файла – только путь, на диске он не хранится. Путь (имя) нужен только чтобы два процесса смогли найти общий канал передачи данных. Тогда уж «всё есть файл» надо переформулировать «всё адресуется как файл».
Пример ТСа с докбаром был бы хорош, будь он релевантен. Там персистентная конфигурация, и добавление файлов в условный config.d во всех смыслах проще, удобнее и надёжнее, чем правка общего конфига. И для людей, и для пакетных менеджеров. Поэтому для конфигов в линуксе используется повсеместно:
# find /etc -name '*.d' -type d 2>/dev/null | wc -l
112
[a1 ~]# find /etc -name '*.d' -type d 2>/dev/null | grep -vF /etc/s6 | wc -l
57
(И это я ещё не вспомнил про /usr/share/applications, ~/.idesktop, и наверняка про многое другое.) Но это не значит, что эту идею надо присобачивать повсюду.
Даже по поводу /proc есть у меня сомнения, не шило ли это на мыло: добавить файл vs добавить системный вызов или поле в структуре. Вызовы-то побыстрее будут: один syscall против трёх: open + read/write + close. Разве что в /proc можно сделать иерархию каталогов, а в сях (в отличие от плюсей) нету namespaces, ну дык это претензия к сям. Получается, отсутствие в языке средств структурирования имён как фактор выбора неэффективного решения.