LINUX.ORG.RU

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

 , , ,


0

4

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

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

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

inb4 Plan9

UPD: понятно, что нельзя все реализовать через файлы. Тот же вывод на экран не сделать через универсальный write(), но контроль доступа, управление и пр. некритичные к производительности вещи вроде как делаются на ура.


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

namezys ★★★★ ()

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

Дураки, сэр.

anonymous ()

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

Zhbert ★★★★★ ()

А если бы сокет открывался каким-нибудь 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 используется на полную мощность, ограничиваясь только целесообразностью.

Krieger_Od ★★ ()
Ответ на: комментарий от gaga

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

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

Zhbert ★★★★★ ()
Ответ на: комментарий от Krieger_Od

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

gaga ()
Ответ на: комментарий от Zhbert

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

gaga ()
Ответ на: комментарий от Krieger_Od

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

gaga ()

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

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

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

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

user_id_68054 ★★★★★ ()
Ответ на: комментарий от gaga

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

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

Zhbert ★★★★★ ()
Ответ на: комментарий от user_id_68054

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

gaga ()
Ответ на: комментарий от gaga

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

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

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

Krieger_Od ★★ ()

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

fish_ka ()
Ответ на: комментарий от Krieger_Od

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

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

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

gaga ()
Ответ на: комментарий от gaga

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

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

Krieger_Od ★★ ()

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

KendovNorok ()

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

/thread

anonymous ()
Ответ на: комментарий от Krieger_Od

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

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

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

ога:

[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

gaga ()
Ответ на: комментарий от gaga

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

anonymous ()

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

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

cat /dev/screen > myscreenshot

beastie ★★★★★ ()

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

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

Legioner ★★★★★ ()

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

anonymous ()

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

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

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

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

Deleted ()

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

crowbar ()

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

redgremlin ★★★★★ ()
Ответ на: комментарий от beastie

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

splinter ★★★★★ ()
Ответ на: комментарий от redgremlin

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

gaga ()

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

dn2010 ★★★★★ ()
Ответ на: комментарий от dn2010

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

gaga ()
Ответ на: комментарий от gaga

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

Krieger_Od ★★ ()

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

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

anonymous ()

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

vurdalak ★★★★★ ()
Ответ на: комментарий от beastie

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

anonymous ()
Ответ на: комментарий от Krieger_Od

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

gaga ()
Последнее исправление: gaga (всего исправлений: 1)

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

пофиксил

anonymous ()
Ответ на: комментарий от gaga

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

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

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

Krieger_Od ★★ ()
Ответ на: комментарий от Krieger_Od

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

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

/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 веке до сих нельзя без адских костылей и геморроя запретить какому-то пользователю выводить, к примеру, звук в правую колонку или читать координаты мыши, а также выполнять с этими вещами другие стандартные операции. Это происходит потому, что все эти подсистемы не экспортируются как какие-нибудь универсальные системные объекты. Это не обязательно файлы, наверняка можно придумать более удобные типы интерфейсов, но ведь их же нет!

gaga ()

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

vasily_pupkin ★★★★★ ()
Ответ на: комментарий от gaga

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

И это другое называется 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 не слыхали?

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

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

Krieger_Od ★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.