Потому что взаимодействуют все как могут, через что придумают и как хотят.

Также PlanB и Inferno.

Почему все забили на такую удобную и простую абстракцию и кинулись делать свой апи?

Дураки, сэр.

Ну, смею предположить, что недокодеров все больше и больше, у многих в голове шиндовс, вот отсюда и пошло-поехало...

А если бы сокет открывался каким-нибудь ioctl'ом на девайсе /dev/tcp/socket, который бы создавал файл /dev/tcp/sockets/443-192.168.1.10

А почему BSD socket API тебя не устраивает, а ioctl устраивает? Даёшь echo «connect 192.168.1.10:443» > /dev/tcp/socket

Не занимайтесь пустыми разговорами. Отцы дали нам BSD sockets как они есть, время проверило концепцию и ничего лучше не появилось.

Концепция файла в *nix используется на полную мощность, ограничиваясь только целесообразностью.

у линуса в голове тоже шиндовс? в его ядре как раз больше всего кастомных апи.

у линуса в голове тоже шиндовс? в его ядре как раз больше всего кастомных апи.

А он до сих пор в одиночку ядро пилит, да?

bsd апи не устраивает тем, о чем я уже писал: контроль доступа существующими средствами. То же и со всем остальным.

Расшифруйте, не понял.

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

ну на файл сокета можно устанавливать обычные rwx права. Это позволило бы, к примеру, разрешать/запрещать конкретному приложению/пользователю пользоваться сетью.

не буду прямо-таки утверждать что доступ через файлы это якобы плохо.. (вопрос спорный, на мой взгляд).

мне кажется что для некритичных к скорости интерфейсов — самое нормальное это DBUS. почему бы и нет :).. намного удобнее чем файл.

а доступ через файлы — во первых требует кода выполняемого в пространстве ядра для создания файла-устройства. во вторых остаётся жирной прослойкой (на каждый файл ещё и распространяется POSIX_ACL).

сумбурно вобщем написал, но думаю суть понятна.

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

Может, ему уже стало пофиг.

Дык ACL это прекрасно же! То, что доктор прописал. Да и не вижу проблемы с созданием файлов в пр-ве ядра: во-первых, это можно обойти, а во-вторых, основные интерфейсы и так делают много чего в ядре.

Это позволило бы, к примеру, разрешать/запрещать конкретному приложению/пользователю пользоваться сетью.

И, пожалуй, ничего больше.

Причина того, что BSD socket API имеет много собственных концепций и не имеет некоторых (не всех) типично-файловых в том, что некоторые типично-файловые сущности неприменимы, и нужны недостающие. И давайте не будем о ioctl() - это такой же сугубо специализированный интерфейс для вызова функций многих ядерных подсистем, как раз противоречащий унификации разных файловых дескрипторов. Однако именно такой штуки - ioctl ли, setsockopt ли - в сетевом программировании нужно немало.

Кроме удобного файлового интерфейса в план9 есть еще чудесные неймспейсы и 9p.

И, пожалуй, ничего больше.

На мой взгляд, это гораздо важнее всего остального. Это именно то, чего отчаянно не хватает сейчас. И это одна из важных причин, почему почти все демоны выполняются от рута, что, на мой взгляд, иначе как идиотизмом назвать нельзя.

Все эти setsockopt и т.п. можно было бы оставить (например, передавать ему дескриптор открытого файла сокета первым аргументом). Можно было бы даже send() оставить как высокоскоростной способ работы в дополнение к write().

На мой взгляд, это гораздо важнее всего остального. Это именно то, чего отчаянно не хватает сейчас. И это одна из важных причин, почему почти все демоны выполняются от рута, что, на мой взгляд, иначе как идиотизмом назвать нельзя.

Ерунда полная. Это «нехватающее» есть. И неправда, что «почти все демоны выполняются от рута». Всё настраивается.

Спроси у разработчиков. Тут только диванные аналитики и фанатики, которые скажут - «ПАТАМУШТА ИДИОТЫЫЫ1111»

Файл недостаточен, а делать более мощную абстракцию как в planb неосилили.

/thread

абстракцию как в planb

какую именно?

«нехватающее» есть

И как оно называется?

неправда, что «почти все демоны выполняются от рута»

ога:

[gaga@packserver ~]$ ps -ef | grep "^root" | wc -l
133
[gaga@packserver ~]$ uname -a
Linux packserver.localdomain 2.6.32-358.14.1.el6.i686 #1 SMP Tue Jul 16 21:12:30 UTC 2013 i686 i686 i386 GNU/Linux

Емнип, она называется box. Но я только по наслышке знаю, в любом случае, так что лучше полуркать в интернетах.

Тот же вывод на экран не сделать через универсальный write()

Мда? ;) В девятом плане таки можно.

cat /dev/screen > myscreenshot

Почему все ушли от юникс-вея в части «все есть файл»?

Потому что этой абстракции недостаточно для эффективной работы с разными объектами операционной системы.

Потому, что парсер текстового говна из /proc /sys это слишком.

cat /dev/fb0 >file

Юникс ой-вэй задолбал.
Да всё ИТ - задолбало.

теперь каждый вилописедет как хочет.

даже такая светлая надежда как ARM - и те задолбали своей огороженностью, так и не став х86 альтернативой.

====
Выдохнул.

Королева во всем разочарована!

Потому, что не «все есть файл».

Потому что эта абстракция неплохо себя чувствовала себя лет так 30 назад. С тех пор мир немного поменялся. А тебе по секрету скажу — и СССР теперь тоже нет.

как то не сильно отличается от cat /dev/fb0 > myscreenshot

А прикол в том, что можно и наоборот:

cat picture > /dev/screen

Прикол в том что тоже самое можно и linux: cat myscreen.raw > /dev/fb0

Мир поменялся в худшую сторону? Потому что теперешние абстракции мало того что не единообразны, так еще и могут меньше.

Потому что для некоторых вещей операции с файлами слишком медленные, даже если файл это абстракция.

Читай сообщения внимательней, про это говорили сто раз.

У Линуса в голове ЧСВ.

Тоже можно.

Афтар, распиши примерно, как с желаемыми тобой механизмами реализовать, к примеру, UDP-сервер, принимающий на одном порту от разных отправителей пакеты и отправляющий им ответы (нечто типа SIP-агента).

Тред не читал.

Потому что это мешает адекватным людям.

По той же причине, по которой в линукс тащат проприетарные игры: блестит.

Такая нелепая ошибка, а бородатый.

sip-агент это не системный сервис, довольно неудобно и неэффективно натягивать на него файловый апи.

Но например:

# ls -R1 /run/sipagent/
/run/sipagent:
pending_requests
block_client
accept_client

/run/sipagent/clients/192.168.1.2:
send
receive
status
#
# echo "this will be sent to client 192.168.1.2" >/run/sipagent/clients/192.168.1.2
# #"read something from client"
# cat /run/sipagent/clients/192.168.1.2
Hello from 192.168.1.2
# cat /run/sipagent/clients/192.168.1.2/status
{
 "connected": true,
 "Rx Bytes": 124543,
 "Tx Bytes": 86540,
 "Idle": false,
 ...
}
# cat /run/sipagent/pending_requests
192.168.1.5
# echo "192.168.1.5" >/run/sipagent/accept_client
# tail -1 /var/log/sipagent
accepted client 192.168.1.5

«юникс-вей есть фейл»

пофиксил

sip-агент это не системный сервис, довольно неудобно и неэффективно натягивать на него файловый апи.

А при чём здесь, системный сервис или нет (да и как судить?). Вы ж боретесь за чистоту всё-есть-файлового подхода.

Из вашего разъяснения пока что ничего не ясно. У вас не фигурируют порты, напрочь. Что, если мы слушаем несколько портов? Да, кстати, такого понятия как «accept» для UDP-протокола нет, есть только индивидуальные пакеты. Как управлять блокируемостью (O_NONBLOCK) передачи данных (в случае TCP)? Чем заменить setsockopt (опции см. в man 7 socket)? И главное - зачем? Чтобы на шелле можно было кодить универсальную обработку сетевой деятельности даже без утилит типа socat?

Нет, я не борюсь за чистоту все-есть-файлового подхода. Наоборот, я выше писал, что те вещи, которые неудобно/неэффективно через файловый апи делать, надо делать через что-то другое. Ну и упомянул, что для меня файловый интерфейс хорош прежде всего возможностью управления доступом независимо от платформы и т.п.

Что, если мы слушаем несколько портов?

/run/sipagent/inports/27015/clients/192.168.1.2

такого понятия как «accept» для UDP-протокола нет

я имел в виду это не для udp, а для сервера, уровнем выше

Как управлять блокируемостью (O_NONBLOCK)

/run/sipagent/config/tcp/block

Чем заменить setsockopt (опции см. в man 7 socket)?

ioctl,devctl, /run/sipagent/clients/192.168.1.2/sockopts/keepalive

И главное - зачем?

В этом примере это вообще не нужно. Причем тут сокеты и sip-агент, это разные уровни и разные вещи? Если переделывать bsd sockets под файловый интерфейс, то можно делать как /net в plan9 или как-то еще. Зачем - универсальный контроль доступа и простота работы, как я уже говорил.

Тут дело даже не в файловом апи как таковом, оно не обязано быть файловым. Просто меня дико бесит, что в 21 веке до сих нельзя без адских костылей и геморроя запретить какому-то пользователю выводить, к примеру, звук в правую колонку или читать координаты мыши, а также выполнять с этими вещами другие стандартные операции. Это происходит потому, что все эти подсистемы не экспортируются как какие-нибудь универсальные системные объекты. Это не обязательно файлы, наверняка можно придумать более удобные типы интерфейсов, но ведь их же нет!

Это же линакс, их тут ахулиард. Посмотри сколько говна поверх LSM накрутили

те вещи, которые неудобно/неэффективно через файловый апи делать, надо делать через что-то другое

И это другое называется BSD sockets API.

такого понятия как «accept» для UDP-протокола нет

я имел в виду это не для udp, а для сервера, уровнем выше

Нет никакого уровня выше. Я вам предложил рассмотреть пример реализации SIP-агента. Он работает по UDP-протоколу. Система SIP-агенту предоставляет сущности UDP-протокола. В UDP-протоколе понятия accept нет. Поэтому ваш ответ по этому пункту не принимается. И реализация работы с такими вещами по вашей идее будет реально адовой.

Как управлять блокируемостью (O_NONBLOCK)

/run/sipagent/config/tcp/block

Для каждого сокета нужно настраивать.

ioctl,devctl

А если задефайнить ioctl для всех абсолютно функций BSD socket API (если для каких-то ещё нету), вы на этом успокоитесь?

Причем тут сокеты и sip-агент, это разные уровни и разные вещи?

Мы реализуем с вами SIP-агент с помощью сокетов. Никаких других сущностей система приложению предоставить пока не может на этот счёт.

Если переделывать bsd sockets под файловый интерфейс, то можно делать как /net в plan9

С интерфейсом plan9 не знаком (можно ссылку?).

или как-то еще

То, что вы пока на конкретном примере предложили, я не могу оценить выше существующего socket API.

Просто меня дико бесит, что в 21 веке до сих нельзя без адских костылей и геморроя

Бгг. Чего злиться, возьми и запили.

выводить, к примеру, звук в правую колонку

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

читать координаты мыши, а также выполнять с этими вещами другие стандартные операции. Это происходит потому, что все эти подсистемы не экспортируются как какие-нибудь универсальные системные объекты

Врёте, батенька. /dev/input/mice не слыхали?

но ведь их же нет!

Учите матчасть. Диспут окончен.

То есть KDBus будет необходим только там, где нужна скорость?