Мне одному кажется, что в этой чудной модели слишком много бессмысленных и бесполезных уровней?

Да, делать mount /dev/sde /mnt/flash && chmod -R 777 /mnt/flash куда круче.

Заведи себе ЖЖ

тоже подумалось

пользователь тыкает в ФМ, который дергает тулкит, который стучится через dbus к udisk-у, который проверяет права доступа через policykit, которому о наличии прав сообщает systemd-logind, который является составной частью инфраструктуры PID 1.

После первых слов дальше не читал. Я просто вставляю флешку.

Олсо, это эе opensource, что ты балаболишь? Где патчи?

Олсо2, а как выглядит правильный класс строки?

История же десктопного линукса представляет собой ни что иное как последовательность попыток правильной реализации монтирования сменных устройств

Именно так. Ни больше, не меньше.

И пора уже этот чертов класс строки всё таки запилить без костылей

И где-же в std::string костыли?

На современном десктопе, чтобы смонтировать несчастную флешку, пользователь тыкает в ФМ, который дергает тулкит, который стучится через dbus к udisk-у, который проверяет права доступа через policykit, которому о наличии прав сообщает systemd-logind, который является составной частью инфраструктуры PID 1.

У тебя какой-то неправильный десктоп. Удев по событию вызывает mount. Всё.

man mount

слишком много бессмысленных и бесполезных уровней?

как минимум 2: тыкает в ФМ, который дергает тулкит
3й сомнительной нужности в данной операции: который стучится через dbus

Потому что пользователь может срузу напрямую попросить udisk, или повесить в фон утилитку, типа tinymount.

который проверяет права доступа через policykit, которому о наличии прав сообщает systemd-logind

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

Хочу такой же табак!

А класс строки мне нравится как сделан в С# и Vala. Собираешь строку StringBuilder'ом и потом она неизменна. - Самая нормальная реализация строк, имхо. И по скорости круто, и пользоваться не слишком сложно.

Это были грибы.

Еще раньше так было сделанно в java, однако при таком подходе substr на 10мб строке приводит к странным эффектам.

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

В Vala все работает очень и очень быстро.

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

Леннарт, перелогиньтесь.

На современном десктопе, чтобы смонтировать несчастную флешку, пользователь тыкает в ФМ, который дергает тулкит, который стучится через dbus к udisk-у, который проверяет права доступа через policykit, которому о наличии прав сообщает systemd-logind, который является составной частью инфраструктуры PID 1.

Когда я вставляю фэшку меня это не беспокоит.

И где-же в std::string костыли?

В UTF.

И по скорости круто

Чем сравнение иммутабельных строк отличается от сравнения std::string? Особенно если учесть, что скорость O(n) достигается алгоритмически, а не мутабельностью-иммутабельностью.

GObject из glib, точнее.

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

4.2 на лоре тормозит все

в этом вашем vala лишние байты для хранения размера строки уходят

в этом вашем vala лишние байты для хранения размера строки уходят

С OpenGL работали? Небось по старой, байто*****й привычке использовали glBegin/glEnd? А то на vertex buffer же видеопамять лишняя уходит.

В кастомных строках внутри компиляторов ещё и хеш-код строки хранится, и ничего, скорость только выше.

Напиши книгу

а потом сожги ее и достигни просветления.

Ммм уже сто лет как цепляет за меня без тыков

udev+fstab/udevil решает

Ставь оригинальный KDE3, там всё через pmount. :)

Экономишь на спичках?

в этом вашем vala лишние байты для хранения размера строки уходят

Зачем на десктопе языки, где len() имеет сложность O(n)?

пользователь тыкает в ФМ, который дергает тулкит, который стучится через dbus к udisk-у, который проверяет права доступа через policykit, которому о наличии прав сообщает systemd-logind

какие-то адовы грибы

udev, говоришь? так это же требуются привилегии рута для написания udev правил.

а ситуация бредовая: я имею доступ к файлу устройства флешки, но не могу примонтировать ее в директорию, владельцем которой являюсь, не обладая правами рута или не обращаясь к программам, имеющим права рута

Уже который раз убеждаюсь, что ты плохо читаешь. Написал одно правило, которое добавляет нужные записи в fstab и пользуйся. Чтобы пользователь мог монтировать используешь опцию users,noauto.

тем не менее, это костыли, когда приходится, пусть и неявно, иметь дело с рутом.

А вот в plan9 и inferno такой проблемы вообще не возникает

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

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

Ну и как это в план9 решается?

Ты что-то делаешь не так. Я втыкаю флешку и она сама монтируется.

а там этой проблемы просто нет

Что-то подобное думал тоже недавно.

//забавно почитать хомячков в этом треде

Что значит просто нет?

это значит, что нет. вообще. архитектура другая.

Вот и расскажи, какая.

во-первых, у каждого процесса свое пространство имен файлов,

во-вторых, понятие рута отсутствует,

в-третьих, монтировать можешь все, что разрешено. И локальных ограничений, вроде бы, нет. Хотя может и есть, но я не сталкивался.

Вот кстати никогда не понимал, почему юзерам запрещено монтировать ФС - если из-за SUID и device nodes, то их можно тупо отключать при монтировании от юзера.

во-первых, у каждого процесса свое пространство имен файлов,

Это я знаю.

во-вторых, понятие рута отсутствует,

А какая там система контроля доступа тогда? Capabilities?

в-третьих, монтировать можешь все, что разрешено.

Это никак не поможет решить проблему «вот носитель, на нем файлы двух пользователей; монтировать могут оба, но каждый получает доступ только к своим файлам».

Race condition. Ядро ничего не знает о том, куда чего можно монтировать, а юзерспейс ничего не знает о том, какой на самом деле файл отрезолвится ядром — его можно подменить после юзерспейсной проверки.

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

Традиция со времён, когда линукс не умел в неймспейсы. С неймспейсом каждому юзеру причин запрещать mount нет.

А между неймспейсами по сети данными обмениваться предложишь?

С неймспейсом каждому юзеру причин запрещать mount нет.

а разве linux поддерживает файловые namespace??

http://en.wikipedia.org/wiki/Cgroups

юзерспейс ничего не знает о том, какой на самом деле файл отрезолвится ядром — его можно подменить после юзерспейсной проверки.

Ну и что? Какая в этом опасность без SUID и devive nodes?

ну так есть:

UTS namespace
IPC namespace
PID namespace
Network namespace

где тут пространства имен файлов?

где тут пространства имен файлов?

Есть и FS namespaces. Ты гуглом совсем не умеешь пользоваться?