Представлен (https://www.freelists.org/post/modular-debian/Announcing-vdev) новый проект vdev (https://github.com/jcnelson/vdev) (virtual device filesystem), нацеленный на разработку менеджера файлов-устройств, выступающего в роли кросс-платформенной и не зависящей от систем инициализации альтернативы udev и devfs. Работа vdev изначально тестируется не только в Linux, но во FreeBSD и OpenBSD.
Vdev представляет собой виртуальную файловую систему, отражающую в форме файлов подключенные к машине устройства. В отличие от devfs (FreeBSD) и udev/eudev/mdev (Linux), Vdev обеспечивает контроль доступа на уровне процессов, не привязанный к особенностям Linux или BSD-систем. Обращение к специфичным особенностям ОС вынесены в отдельную прослойку, в то время как базовая логика абстрагирована от предоставляемого операционными системами API доступа к устройствам.В Vdev используется похожая на devfs и udev событийная (Event-driven) модель работы с устройствами, позволяющая на лету добавлять новые устройства и исключать отключенные. Для выполнения данных задач в vdev поддерживаются различные системные API получения уведомлений об изменении состояния оборудования. При этом источником связанных с оборудованием событий может быть не только операционная система, но и другие экземпляры vdev или правки существующего дерева /dev, что делает vdev интересным решением для систем контейнерной виртуализации. Как и в devfs, в vdev реализована возможность отображения для процессов различного контекста корневого дерева устройств, в зависимости от заданных прав доступа.
Особенностью vdev является расширенная система управления доступом, позволяющая задавать фильтры, ограничивающие доступ к дереву устройств не только на основании штатных прав доступа и идентификаторов пользователей/групп, но и в привязке к заданным процессам. Подобный подход позволяет обойтись без установки флагов setuid/setgid и без менеджера управления сеансами при необходимости предоставления процессу доступа к привилегированным файлам устройств. Например, доступ к /dev/dri/* и /dev/input/* может быть предоставлен процессу /usr/bin/X, независимо от пользователя под которым он запущен, что позволяет обойтись без systemd-logind.
Код проекта написан на языке C++ и распространяется (https://github.com/jcnelson/vdev) под лицензией GPLv3. Виртуальная файловая система создаётся с использованием механизма FUSE. Из зависимостей отмечаются OpenSSL, libfuse, libc, libstdc++ (для STL) и
libpthread, а также библиотеки fskit (https://github.com/jcnelson/fskit) и libpstat (https://github.com/jcnelson/libpstat), развиваемые автором vdev.
URL: https://www.freelists.org/post/modular-debian/Announcing-vdev
Новость: http://www.opennet.me/opennews/art.shtml?num=41328
И все хором: "И никакого systemd!"
Не, всё гораздо прозаичнее - "О, ещё один!"Я их уже забывать начинаю, перед devtmpfs, был devfs, (между ними что-то мелкое тоже было),
до devfs что-то было и даже на ядре 2.4, ядро 2.2 я где-то гулял, на ядре 2.0 тоже было.
specfs, streamfs, miscfs,...
тянуть в зависимостях openssl да ещё и через fuse? воу воу палехчи!
и будут войны монстров жирдяя с двухглавым
Как вы забодали, нет такого слова "жирдяй", есть "жердяй", от слова "жердь" - длинный и тощий, чтобы себе не думали переводчики Симпсонов
Как вы забодали говорить, что нет такого слова "жирдяй", есть "жирдяй", от слова "жир" - толстый и жирный, чтобы себе не думали переводчики Симпсонов
для жирных есть слово "жиртрест"
> для жирных есть слово "жиртрест"я жирным не указываю как себя называть, если хотят жиртрест -- пусть будет жиртрест.
я жирных буду называть так, как хочу, например жирдяй
> для жирных есть слово "жиртрест"Нет слова "жиртрест" (трест жира??), есть слово жиртрес.
> Как вы забодали говорить, что нет такого слова "жирдяй", есть "жирдяй", от
> слова "жир" - толстый и жирный, чтобы себе не думали переводчики
> СимпсоновКак вы забодали говорить "чтобы" тогда, когда надо "что бы".
> Как вы забодали, нет такого слова "жирдяй", есть "жердяй", от слова "жердь"
> - длинный и тощий, чтобы себе не думали переводчики Симпсоновты феерический идиот.
> тянуть в зависимостях openssl да ещё и через fuse? воу воу палехчи!Чтобы убить systemd, нужно самому стать systemd.
> Чтобы убить systemd, нужно самому стать systemd.Чтобы убить systemd - надо стать еще фичастее чем он. Собственно отсутствие фич и нежелание решать существующие проблемы - то что сгубило апстарт и openrc как конкурентов systemd в дебиане.
>> Чтобы убить systemd, нужно самому стать systemd.
> systemd
> решать существующие проблемыЛовко ты на ноль поделил.
я так понимаю, что списка наличиствующих проблем и фитч, которые невозможно прикрутить к openrc не будет?
только манифест?
>> тянуть в зависимостях openssl да ещё и через fuse? воу воу палехчи!
>Чтобы убить systemd, нужно самому стать systemd.Это полная противоположность поттеринг-вэй. Чтобы сделать как в системд, надо изобрести свои ни с чем не совместимые cryptod и filesystemd и безальтернативно связать их со всеми остальными .*d.
> не только в Linux, но во FreeBSD и OpenBSDПохвально. Люди объявили о намерении писать культурно и аккуратно.
только в openbsd не оценят GPLv3 ;)
> только в openbsd не оценят GPLv3 ;)Давно пора закинуть в это замшелое болото пару свежих гранат.
Теперь я знаю, что такое свежая граната. Хотелось бы ещё посмотреть, как выглядит тухлая граната.
Точно так же, как и свежая. Но не взрывается. Потому что протухла.
Ms-PL?
> только в openbsd не оценят GPLv3 ;)Это как раз не проблема. Аффтар написал что согласен на 2-е лицензирование GPL/BSD или GPL/MIT
Да полноте, могут говорить что хотят. Вон pulseaudio тоже обещали сразу и для всех, а по факту на бзде оно так никому и не нужно. Потому что одно дело обещать кучу вкусняшек и совершенно другое - решать реальные проблемы. Я не могу вспомнить проблем со звуком под бздю которые бы решала пульса, ровно как я и не вижу проблем с devfs которые может решить vdev. Такое впечатление что единственная проблема которую пытаются задекларировать товарищи - то что во бзде всё работает не так как в линуксе.Вобщем если у товарищей действительно что-то получится портабельное и эффективное - удачи им. Но что-то мне кажется что получится как с systemd - решили портануть launchd но в процессе портирования во лбу проросла фара а из жопы грабли.
> а по факту на бзде оно так никому и не нужноСпикеру не нужна любая звуковая подсистема. ;-)
> Я не могу вспомнить проблем со звуком под бздю которые бы решала пульсаНапример раздельная регулировка громкости для наушников и строенных динамиков в буке. Автоматическое переключение вывода в них же. Переключение звука на hdmi. Раздельное регулирование звука для приложений.
>> Я не могу вспомнить проблем со звуком под бздю которые бы решала пульса
> Например раздельная регулировка громкости для наушников и строенных динамиков в буке. Автоматическое
> переключение вывода в них же. Переключение звука на hdmi. Раздельное регулирование
> звука для приложений.Согласен, теперь давай померяемся. Более полная и стабильная поддержка устройств включая те которые линукс уже не поддерживает, поддержка виртуальных каналов на уровне ядра - всё это нужно выкинуть ради управления разными входами/выходами? Зачем менять велосипед без седла на велосипед без колёс? Может лучше доработать то что есть?
> Может лучше доработать то что есть?Ну так доработай. А то что-то критиканы пульса умеют только поливать помоями и вопить про ненyжность. А потом удивляются когда половина программ ни о чем кроме него и слышать не хочет. Потому что остальное не покрывает даже нужды авторов тех программ для их повседневной активности типа втыкания наушников в ноут или подключения по HDMI.
> Потому что остальное не покрывает даже нужды авторов тех программ для их повседневной активности типа втыкания наушников в ноут или подключения по HDMI.ТруЪ юниксоид вам сразу заявит, что ему совершенно не проблема написать костыль на шелле, чтобы он передергивал ALSA при втыкании наушников. По команде из рутовой консоли, да.
> из рутовой консоли, да.А пульс сам все это делает. По факту втыкания ушей.
>> из рутовой консоли, да.
> А пульс сам все это делает. По факту втыкания ушей.ах, если бы, ах, если бы. купивши в своё время Aspire One поиграться, я так и не смог заставить дебиан с пульсой отрубать внешние динамики при подключении наушников и врубать при выключении. проблема решилась сносом дебиана и установкой слаки, которая из коробки вела себя именно так. при этом пульсы в слаке отродясь не было.
> сносом дебиана и установкой слаки, которая из коробки вела себя именно
> так. при этом пульсы в слаке отродясь не было.Ну а у меня на ноуте хубунта с пульсом себя по дефолту ведет именно вот так. И пульс еще и разные уровни помнит для разных девайсов. Что чертовски логично, ибо уши одно а динамики другое.
Что еще веселее - к нему есть гуйная утилита где можно визуально ткнуть всякие там дефолтные (fallback) девайсы и прочее. Актуально для более-менее современных компов где сразу из коробки по 2-3 звуковухи (видеокарты с HDMI нынче тоже звуковухи) и совсем не факт что дефолтной будет та которую хотелось. Скажем прямо - мне удобнее и интуитивнее ткнуть в гуе "сделать вот его дефолтным" чем колупаться в конфигах среди каких-нибудь технических обозначений, просадив на это в 5 раз больше времени. При том что на данный момент я не очень в курсе куда мне пристроить знания о продвинутом конфигурировании алсучки и зачем мне это может быть полезно.
я, кагбэ, мягко намекал, что утверждение «пульса решает проблемы, а алса не умеет» — ЛПП.то, что алса — набор хреново документированой фигни, — в данном случае к делу отношения не имеет. пульс не лучше, да вдобавок ещё одну унылую абстракцию навешивает.
а дело в том, что в своё время делать подобное для алсы было ненужно. точнее, может, и нужно, но ненужно тем, кто мог. а теперь и подавно не будут, потому что давно уже всё себе отконфигурили, что хотели, запилили и не напрягаются. соответственно, тем, кто может, гуй уже не нужен, а теи, кто не могут… ну, они не могут.
да и хрен с ним, у нас в слаке пульсы нет, а потому всё хорошо.
> ТруЪ юниксоид вам сразу заявит, что ему совершенно
> не проблема написать костыль на шелле,
> чтобы он передергивал ALSA при втыкании наушников.
> По команде из рутовой консоли, да.Не благодари за то, что разыскал за тебя:
https://wiki.archlinux.org/index.php/Advanced_Linux_Sound_Ar...Контроль пути к sh обязательно.
Не у всех он лежит в /usr/bin
>> Может лучше доработать то что есть?
> Ну так доработай. А то что-то критиканы пульса умеют только поливать помоями
> и вопить про ненyжность. А потом удивляются когда половина программ ни
> о чем кроме него и слышать не хочет. Потому что остальное
> не покрывает даже нужды авторов тех программ для их повседневной активности
> типа втыкания наушников в ноут или подключения по HDMI.Да, желание на каждый чих плодить новый интерфейс не совместимый больше ни с чем - тоже серъёзная проблема. И да, я не собираюсь допиливать пульсу до минимально устраивающего меня уровня, пусть этот кактус жрут те у кого повседневная активность состоит из втыкания наушников или подключения по HDMI. Да, у пульсы есть хорошие фишки, но пока мне они не важны так что и саму пульсу я терпеть не намерен при наличии куда более надёжных и прямых интерфейсов.
> с чем - тоже серъёзная проблема.Серьезная проблема - это упыри, полагающие что подключение к нотику наушников или там какой-то вывод на телек с видеокарты по HDMI (видяха до кучи еще и звуковуха нынче) - должен быть рокетсайнсом, требующим ЦУПа и группу из нескольких ракетных инженеров и пары ученых для проведения орбитальной, блин, миссии - стыковки двух бытовых приборов!
А у нормальных людей все это работает в режиме плагнплей. И пингвин так тоже может. В том числе и благодаря пульсу. И последнее что я хочу - это разучивать десяток нафигнужных мне команд алсы без сильной причины. И нет, втыкание наушников или подключение телевизора - на кастом вообще совсем никак не тянет. Это совершенно обыденное повседневное действо, которое миллионы людей по всей планете делают ежедневно. И имеют все основания полагать что это должно работать в виде "воткнул провод - пошел звук". Как минимум пока нет зело крутых требований вида "а давайте с 23 до 7 утра гнать звук на наушники, чтобы никому не мешать, а в 9 утра врубим что-нибудь хардкорное - на телек с его громкими динамиками".
> И да, я не собираюсь допиливать пульсу до минимально устраивающего меня уровня,А это лично ваши проблемы. Всякие типовые сценарии оно обрабатывает неплохо и логично. А кастом на то и кастом что придется поднапрячься. Только вот см. выше про наушники и телеки - элементарное подключение устройства вывода звука само по себе на кастом явно не тянет.
> те у кого повседневная активность состоит из втыкания наушников или подключения по HDMI.
А чего такого в этой реальности? oO
> намерен при наличии куда более надёжных и прямых интерфейсов.
А решение для автоматического переключения на наушники при их втыкании вы так и не предложили, а отличие от пульса. Который допирает что раз воткнули - то наверное для того чтобы звук играть. И даже понимает что звук на динамики - не то же самое что и на наушники. В плане уровня громкости. Поэтому ушам одно, динамикам - другое. Я сам чтоли должен такое колхозить?
> культурно и аккуратно.Это точно про фиговину с FUSE, SSL и прочим?
>> культурно и аккуратно.
> Это точно про фиговину с FUSE, SSL и прочим?Нет. На самом деле, "культурно и аккуратно" должно быть на Java. Тогда оно запустится не только на *BSD, но и на Windows.
Тогда уж и на JS. Еще и в браузере заработает.
FUSE, openssl, кресты - не взлетит.
Кроме этого -- не ясно зачем писать замену udev и logind, учитывая что udev и logind хорошие инструменты (хорошо выполняют своё дело и являются частью systemd, хорошо себя зарекомендовавшей)
> и являются частью systemdэто и есть основная проблема
> это и есть основная проблема...для НеФанатов.
>> это и есть основная проблема
> ...для НеФанатов.Ага, конечно. Вовсе не фанатов, а на редкость трезвомыслящих людей. Которые могут аргументировать свое мнение, а не тупо изливать эмоции.
> Ага, конечно. Вовсе не фанатов, а на редкость трезвомыслящих людей. Которые могут
> аргументировать свое мнение, а не тупо изливать эмоции.Образец НеФанатского сообщения - можно заносить в парижскую палату мер и весов.
>> и являются частью systemd
> это и есть основная проблемагде здесь проблема? systemd это промышленный стандарт. какой смысл от systemd избавляться?
>>> и являются частью systemd
>> это и есть основная проблема
> где здесь проблема? systemd это промышленный стандарт. какой смысл от systemd избавляться?когда systemd стал стандартом, да ещё и промышленным? я что--то пропустил?
> когда systemd стал стандартом, да ещё и промышленным? я что--то пропустил?Ну, понимаешь, гента, слака и прочие арчи в промышленности мало применяются. А вот редхат, зюя, а в перспективе и дебиан с убунтами, которые в основном как раз и составляют эти самые продакшны - ну ты понял. Впрочем, арч хоть и не продакшн но тоже сдался Саурону.
Ну вот пройдёт ещё года три, если к тому времени эти ваши systemd не сдохнут - тогда они и доползут до продакшна вместе с соответствующими версиями операционок. Ну, или получится как с devfs/hal.
Подтверждаю, 6.х центос и редхат еще поддерживаются, и будут поддерживаться довольно долго, 7.х с системд едва вышел из теста, еще тонны софта непонятно как будут с этим взаимодействовать, тестировать надо. А это куча времени, так что до стандарта еще пилить и пилить.
> Подтверждаю, 6.х центос и редхат еще поддерживаются, и будут поддерживаться довольно долго,
> 7.х с системд едва вышел из теста, еще тонны софта непонятно
> как будут с этим взаимодействовать, тестировать надо. А это куча времени,
> так что до стандарта еще пилить и пилить.В новых инсталляциях промышленных линуксов (RHEL/SLES/OL) systemd _уже_ по умолчанию.
Поздно что-то пилить и тестировать, все уже давно сделано.
> systemd не сдохнут - тогда они и доползут до продакшна вместе
> с соответствующими версиями операционок.Рхел 7.х и соответствующие центоси уже релизнулись. Дебиан - наверное через годик раздуплится, как обычно. Убунты обещали в 15.04 вроде. Хотя по факту в 14.10 системд уже притащен, но пока еще не запущен как дефолтная система инициализации.
> Ну, или получится как с devfs/hal.
Да, там стал udev. Который теперь вообще субпроект systemd. Тебе сильно полегчало? :)
> Да, там стал udev. Который теперь вообще субпроект systemd....и которому уже 2 альтернативы. :-) Сами выбрали этот путь, теперь пусть не удивляются, что их постигла участь hal'а.
> ...и которому уже 2 альтернативы. :-)Пока что эти проекты не производят впечатление реальных альтернатив.
> Сами выбрали этот путь, теперь пусть не удивляются, что их постигла участь hal'а.
Вообще-то, udev изначально разрабатывался командой systemd - Кроа-Хартманом и Сайверсом. Через пару лет к ним подключился Поттеринг, еще через пару - появился systemd, еще через пару - проекты объединились.
> ...и которому уже 2 альтернативы. :-)При том глядя на обе из них понятно что не "для людей" а "чтоб было". Спасибо еще если не "чтобы подкачать ЧСВ".
"Релизнулись" и "Массово применяются в продакшне" для дебиана отличаются года на два, для редхата - и на все четыре. Потому что массу существующих систем никто в здравом уме мигрировать без нужды не будет, и пока эта нужда возникнет (а заодно пока наберётся масса новых инсталлов) - те самые годы и проходят.А насчет hal/devfs - объясняю специально для тех, кто недопонимает. Их очень хвалили и затащили, считай, во все дистры. Что ни разу им не помешало довольно быстро и бесславно помереть. И с systemd такое очень даже может (и должно, как по мне) случиться. Это не значит, что будет возврат к sysvinit - но вот этот самоваропаровозоветролёт явно должен быть заменён на что-то более вменяемо спроектированное и более разумным лидом.
> "Релизнулись" и "Массово применяются в продакшне" для дебиана отличаются года на два,Это уже не принципиально. There is no turning back at this point.
> пока эта нужда возникнет (а заодно пока наберётся масса новых инсталлов)
> - те самые годы и проходят.В любом случае, мир изменился. Даже если systemd будет заменен, новая система будет сделана по образу и подобию и иметь очень похожий дизайн. Первым это придумали вообще Шатлворт и Ко. А Поттеринг лишь оценил перспективы да доразвил. И если уж даже мелкие опенвртшники равняются на это - ну ты понял.
В хучшем случае ты окажешься прав и ... придет замена. Поскольку мир становится сложнее, на ее фоне про системд будут говорить то же что сейчас говорят про апстарт на фоне системды.
> не помешало довольно быстро и бесславно помереть.
А вон в моем N900 - до сих пор есть и работает. Хоть и выглядит немного архаичненько по современым временам.
> И с systemd такое очень даже может (и должно, как по мне) случиться.
Если это случится - ты имхо пожалеешь что поттера поливал. Когда появился апстарт - его поливали помоями как сейчас поттера. Потом пришел поттер и оказалось что апстарт был не такой уж и плохой :). Несложно предугадать что скажут про поттера когда придет замена...
> явно должен быть заменён на что-то более вменяемо спроектированное и более
> разумным лидом.Понятия вменяемости и разумности лида по параметрам которые колышут тебя - ни разу не обязаны совпадать с мнением большинства пользователей, разработчиков и майнтайнеров по этому поводу. Поэтому имхо большой вопрос насколько ты будешь рад это получить. Но ок, за поливание апстарта олдскульным фаготам воздалось воистину эпично. Было бы неплохо чтобы за поттера вышло не хуже :). Потому что нельзя быть таким гoвном!
>> когда systemd стал стандартом, да ещё и промышленным? я что--то пропустил?
> Ну, понимаешь, гента, слака и прочие арчи в промышленности мало применяются. А
> вот редхат, зюя, а в перспективе и дебиан с убунтами, которые
> в основном как раз и составляют эти самые продакшны - ну
> ты понял. Впрочем, арч хоть и не продакшн но тоже сдался
> Саурону.ты свои фантазии со стандартами перепутал
> ты свои фантазии со стандартами перепуталС фантазиями, пожалуйста - на винду, фрю и другие lennart-free OS.
А в линуксе правит бал systemd, и с этим ничего уже не сделать.
> А в линуксе правит бал systemd, и с этим ничего уже не сделать.Это вы эмедовщикам расскажите, вот они удивятся.
> Это вы эмедовщикам расскажите, вот они удивятся.Опенвртшники вас услышали и сделали свой, карманный вариант :)
> когда systemd стал стандартом, да ещё и промышленным? я что--то пропустил?С тех пор, как его по умолчанию стали использовать все три промышленных дистрибутива Linux.
> systemd это промышленный стандарт.Я что-то пропустил? Кто принял? ISO? ITU? Номерочек не назовете?
Ну, стандарт де-факто - это тоже стандарт, покруче формально принятых. Только чтобы systemd стала стандартом де-факто (то есть жить на подавляющем большинстве систем) в реальном использовании - должно лет пять-семь пройти. Я так смотрю - он столько банально не проживёт.
> Ну, стандарт де-факто - это тоже стандарт, покруче формально принятых. Только чтобы
> systemd стала стандартом де-факто (то есть жить на подавляющем большинстве систем)
> в реальном использованииЧтобы что-то стало стандартом де-факто - достаточно, чтобы оно было на большинстве свежеустановленных систем. А у systemd с этим никаких проблем нет уже давно.
Стандарт де-факто - это когда можно ни на что остально ене оглядываться. Для этого надо иметь подавляющее большинство систем, а не только свежие инсталлы, доля которых в общей массе - копейки. И даже на свежеустановленных он оказывается только на совсем новых проектах, которые не тянут RHEL 6 на уже существующих машинах. А кто тянет - как правило, стараются без нужды зоопарк не разводить и ставят всё ту же шестёрку.
> где здесь проблема? systemd это промышленный стандартНе стандарт, а дефолт. И не промышленный, а дектопный.
Ибо даже RedHat включили его по дефолту лишь в середине 2014 года, а SuSe и того позже. Так что, спешу вас огорчить: 99% Линуксов и ентерпрайсе работают далеко не systemd.
> Не стандарт, а дефолт. И не промышленный, а дектопный.
>
> Ибо даже RedHat включили его по дефолту лишь в середине 2014 года, а SuSe и того позже. > Так что, спешу вас огорчить: 99% Линуксов и ентерпрайсе работают далеко не systemd.если ты такой умный, то назови пожалуйста названия дистрибутивов, в которых приняли (ды ещё и по дефолту) vdev вместо systemd ?
или ты такой хитрый решил что для systemd требуется *особая* более предвзятая критика?
нет! не прокатило! здесь не дурачки сидят, и всдят всю эту двуличность при сравнении програм..
> нет! не прокатило! здесь не дурачки сидят, и всдят всю эту двуличность при сравнении програм..Как будто что-то плохое.
Никто и не скрывает, что наезды на поттера идут по заказу мелкософта. Главное - завалить линукс, и сами линуксоиды - лучшие помощники в этом.
> Никто и не скрывает, что наезды на поттера идут по заказу мелкософта.
> Главное - завалить линукс, и сами линуксоиды - лучшие помощники в
> этом."Когда Вы говорите, Иван Васильевич, впечатление такое, что Вы бредите."
Откуда-откуда, говоришь, приехала "комманда systemd" (ленарт, кей, грег)? Из suse-novell-microsoft GMBH? Конечно, именно они и защищают "линукс" от нападок "линуксоидов", а нападки эти - "по заказу мелкософта".
___Ждите! Психиатр на подходе. Срочный случай: [ин]версии, передёрги, словесная диарея, отрыв от реальности.
> Ибо даже RedHat включили его по дефолту лишь в середине 2014 года, а SuSe и того позже. Так что, спешу вас огорчить: 99% Линуксов и ентерпрайсе работают далеко не systemd.Т.е. новых инсталляций промышленных линуксов с 2014 не было и не будет?
>> где здесь проблема? systemd это промышленный стандарт
> Не стандарт, а дефолт. И не промышленный, а дектопный.С каких это пор RHEL и SLES стали десктопными дистрами?
> где здесь проблема? systemd это промышленный стандарт. какой смысл от systemd избавляться?Стандарт ограничивает свободу. Если все делать по стандарту, не останется места для самовыражения.
>> и являются частью systemd
> это и есть основная проблемаНе большая, чем ядро Linux.
Ваша попытка потролить засчитана.
Глупый школьник не отличает утилиту от технологии.
Технология systemd, утилита logind и udev.
Есть ещё технологии Unix, Linux, Windows...
> Ваша попытка потролить засчитана.
> Глупый школьник не отличает утилиту от технологии.
> Технология systemd, утилита logind и udev.
> Есть ещё технологии Unix, Linux, Windows...У тебя Ынтерпрайз головного мозга. Unix и Windows - это ОС. Linux - это ядро. Любят некоторые всё, что не понимают называть технологиями. В словарь загляни для начала.
OpenSSL в сообщении есть, а в dependencies нет нигде (https://github.com/jcnelson/vdev#dependencies). Так таки нужен или нет?
> OpenSSL в сообщении есть, а в dependencies нет нигдеOpenSSL используется в libpstat, которая есть в зависимостях у vdev https://github.com/jcnelson/libpstat/blob/master/Makefile
В анонсе об этом написано https://www.freelists.org/post/modular-debian/Announcing-vdevThe dependencies are:
* fskit (another project of mine)
* libpstat (another project of mine)
* OpenSSL
* libfuse
* libc
* libstdc++ (for STL)
* libpthread
> The dependencies are:
> * fskit (another project of mine)
> * libpstat (another project of mine)
> * OpenSSL
> * libfuse
> * libc
> * libstdc++ (for STL)
> * libpthreadНу то-есть, догнать и перегнать системд? Nice try! :). Это заметим для замены всего лишь одного удава на сях. Представляю как они навернут для остальных компонентов.
> Ну то-есть, догнать и перегнать системд? Nice try! :). Это заметим для
> замены всего лишь одного удава на сях. Представляю как они навернут
> для остальных компонентов.Зато все юниксвейно, в отличие от.
> Зато все юниксвейно, в отличие от.И докучи еще кроссплатформенно, что по мнению авторов systemГ вообще является ересью
Вот вы этим и пользуйтесь :). Такой список либ в автоцеплялке железа - ересь иррелевантно ко всему остальному. Плюсовый стдлиб припереть? А чо не яву сразу?!
> OpenSSL используется в libpstat, которая есть в зависимостях у vdev https://github.com/jcnelson/libpstat/blob/master/MakefileУпс, проглядел. Спасибо )).
В принципе, openssl, как я понял, там только для того, чтобы считать sha256-хэш. Вполне возможно, что и отвяжут, ИМХО.
> openssl, как я понял, там только для того, чтобы считать sha256-хэш.На фоне такой логики - Гарри Поттер, пожалуй, хороший мальчик.
А плюсы наверное тогда для того чтобы // в коментах можно было :).
Будущее наступило - хорошо, что не на яве с питонами.
> Будущее наступило - хорошо, что не на яве с питонами.Ничего хорошего. Привязка к крестам и FUSE сильно ограничивают портируемость решения.
Посмотрел код, там нормальный Cи.
> являются частью systemdэто и есть основная проблема
Мне одному кажется, что прибивать полномочия к путям файлов - идиотская идея? А если у нас не /usr/bin/X, а /usr/local/bin/X-experimental - тогда что?
> Мне одному кажется, что прибивать полномочия к путям файлов - идиотская идея?
> А если у нас не /usr/bin/X, а /usr/local/bin/X-experimental - тогда что?так там не написано про "путь к файлу", написано про процесс.
Дорогой школьник, процесс нужно как-то идентифицировать. Может расскажешь как, если не через путь к файлу?
> Дорогой школьник, процесс нужно как-то идентифицировать.
> Может расскажешь как, если не через путь к файлу?Через метки SELinux, например.
> Через метки SELinux, например.А где их возьмут фрибздуны и прочие некрофаги?
>> Через метки SELinux, например.
> А где их возьмут фрибздуны и прочие некрофаги?ну тот-же android подсказывает более универсальный способ -- т.е. через запуск отдельных процессов под разными uid -- что вполне кросплатформенно.
>>> Через метки SELinux, например.
>> А где их возьмут фрибздуны и прочие некрофаги?
> ну тот-же android подсказывает более универсальный способ -- т.е. через запуск отдельных
> процессов под разными uid -- что вполне кросплатформенно.полномочия через uid\gid -- всегда были (например можно создать спец-группу и поместить в неё файл /dev/input ).
и вся суть systemd-logind в том что как раз недостаточно этих uid\gid , так как "спец-группа" не способна разрулить тонкие моменты.
>>>> Через метки SELinux, например.
>>> А где их возьмут фрибздуны и прочие некрофаги?
>> ну тот-же android подсказывает более универсальный способ -- т.е. через запуск отдельных
>> процессов под разными uid -- что вполне кросплатформенно.
> полномочия через uid\gid -- всегда были (например можно создать спец-группу и поместить
> в неё файл /dev/input ).
> и вся суть systemd-logind в том что как раз недостаточно этих uid\gid
> , так как "спец-группа" не способна разрулить тонкие моменты.я конечно в этих ваших systemd ничего не понимаю от слова совсем, но таки что не получается разделить? объясните мне, пожалуйста
скорее всего у руля неграмотное чмо, с дбасом NIH-синдрома головного мозга, потому и не получается
> скорее всего у руля неграмотное чмо, с дбасом NIH-синдрома головного мозга, потому и не получаетсяСкорее всего, безграмотный ламерок-анонимус не читал, но осуждает =)
> но таки что не получается разделить? объясните мне, пожалуйстанужно запустить дисплейный сервер с пониженными привелегиями. и чтобы ОН имел бы доступ к /dev/input , а программы работающие внутри него -- НЕ имели бы.
а uid\gid могут либо разрешить сразу всем (и дисплейному серверу и программам), либо не разрешить ни кому кроме root\suid.
>> но таки что не получается разделить? объясните мне, пожалуйста
> нужно запустить дисплейный сервер с пониженными привелегиями. и чтобы ОН имел бы
> доступ к /dev/input , а программы работающие внутри него -- НЕ
> имели бы.
> а uid\gid могут либо разрешить сразу всем (и дисплейному серверу и программам),
> либо не разрешить ни кому кроме root\suid.какое отношение имеют привелегии Xwindow сервере к привелегиям программ отображающих своё содержимое на этом сервере?
> какое отношение имеют привелегии Xwindow сервере к привелегиям программ отображающих своё содержимое на этом сервере?При том, что запущенный Васей пасьянс не должен иметь прямого доступа к устройствам ввода-вывода, в отличие от запущенных Васей иксов. Решений может быть несколько - запускать иксы от рута, проксировать доступ к устройствам через logind, или громоздить FUSE-костыли наподобие сабжа.
>> какое отношение имеют привелегии Xwindow сервере к привелегиям программ отображающих своё содержимое на этом сервере?
> При том, что запущенный Васей пасьянс не должен иметь прямого доступа к
> устройствам ввода-вывода, в отличие от запущенных Васей иксов. Решений может быть
> несколько - запускать иксы от рута, проксировать доступ к устройствам через
> logind, или громоздить FUSE-костыли наподобие сабжа.тебе я так понимаю понятие о xinput недоступно, и ты не понимаешь что /dev/inputXX открывает xwindow а не программа, подключившаяся к иксам, а вот потом, когда иксы получили инпут -- они в зависимости от текущего контекста (например активно ли конкретное окно) передают приложению xev (которые от x window events).
анонимы всё тупее.
> ну тот-же android подсказывает более универсальный способ -- т.е. через запуск отдельных
> процессов под разными uid -- что вполне кросплатформенно.А, то-есть у меня по дефолту должно быть 50 юзеров в системе? Спасибо, мы это уже видали. В древних юниксах и винде. И как-то это сильно зacиpaло список юзерей.
> А, то-есть у меня по дефолту должно быть 50 юзеров в системе?
> Спасибо, мы это уже видали. В древних юниксах и винде. И
> как-то это сильно зacиpaло список юзерей.А в современных юникс-подобных точно так же.
Например, на ноуте, с которого пишу это сообщение ’cat /etc/passwd | wc -l’ показывает 34. Из них с правом входа - 1 ;) В чем Вы видите проблему?
А вот по поводу "винды" - там , на сколько мне извесно, скрытых системных всего 3. А в древних "виндах" (3.х, 95, 98, ме) - их, собственно, вообще небыло, так, видимость одна.
> В чем Вы видите проблему?В срaче в конфиг всяким барахлом на уровне который заставляет вспомнить виндовый реестр, при том что 90% потом не используется.
> А вот по поводу "винды" - там , на сколько мне извесно,
> скрытых системных всего 3.Ээээ под рукой винды нет но навскидку в современных виндах их там целая толпа по дефолту. Как раз для запуска сервисов всех мастей и прочая. И с урезанными правами и с полными, и для сетевых сервисов и локальных, аккаунты саппортов, системы, гуеста, и кого там блин еще. Некоторые к тому же мегаособенные, что позволяет компетентным людям срубать массу лулзов, когда какой-нибудь малоприметный юзер оказывается дофига привилегированным и хренудаляемым.
> А в древних "виндах" (3.х, 95, 98, ме) - их, собственно, вообще
> небыло, так, видимость одна.Ну вы тоже мне захотели - систему прав в DOS-extender'ах.
> В срaче в конфиг всяким барахлом на уровне который заставляет вспомнить виндовый реестр, при том что 90% потом не используется.Не трогай птичку! Мы отлично увидели что получается из намерения "упростить" на примере systemd. Инит с килобайтов кода вырос до пары мегабайт, на порядки(!), в генераторах юнитов сейчас сам поттеринг ногу сломит, зависимости юнитов - без поллитры и graphviz'а не разберёшься. Документацию оне пока ещё пишут, но уже появляются заглушки в манах в стиле "сепульки - устройства для сепуления".
> Не трогай птичку! Мы отлично увидели что получается из намерения "упростить" на
> примере systemd. Инит с килобайтов кода вырос до пары мегабайт, на
> порядки(!), в генераторах юнитов сейчас сам поттеринг ногу сломит, зависимости юнитов
> - без поллитры и graphviz'а не разберёшься. Документацию оне пока ещё
> пишут, но уже появляются заглушки в манах в стиле "сепульки -
> устройства для сепуления".Энивей, это все равно на порядок проще, чем километровый портянки скриптовых костылей, причем свои в каждом дистрибутиве.
> Энивей, это все равно на порядок проще, чем километровый портянки скриптовых костылей,
> причем свои в каждом дистрибутиве.ЧСХ дебианщики это практически прямым текстом признали и признали что если они не сделают выбор сейчас по изменению этой ситуации - станут неактуальны как дистр. Потому что как видим, большинству майнтайнеров sysv крап сидит в печенках. OpenRC ничего принципиально не меняет. А апстарт - просто проиграл развитие системд. Не давились бы жабой по части CLA и развивали бы поактивнее (особенно контейнеры/виртуалки) - может и не загнулись бы. А так системд сильно обошел их и по фичам и по контрибуторам.
>> ну тот-же android подсказывает более универсальный способ -- т.е. через запуск отдельных
>> процессов под разными uid -- что вполне кросплатформенно.
> А, то-есть у меня по дефолту должно быть 50 юзеров в системе?
> Спасибо, мы это уже видали. В древних юниксах и винде. И
> как-то это сильно зacиpaло список юзерей.во первых запуск процесса подопределённым uid совсем не требует создание каких-либо уч.записей. во вторых тут нет проблемы.
> во первых запуск процесса подопределённым uid совсем не требует создание каких-либо уч.записей.
> во вторых тут нет проблемы.Ага. UID назначать рандомно.
> Ага. UID назначать рандомно.И, поиграв немного в гонки с рандомом, юзерь Вася сможет стать еще и дисплейным сервером. Или там кем еще.
> А, то-есть у меня по дефолту должно быть 50 юзеров в системе?и в чём проблема?
# wc -l /etc/shadow
54 /etc/shadow> Спасибо, мы это уже видали. В древних юниксах и винде. И
> как-то это сильно зacиpaло список юзерей.ты что, каждый раз cat ему делаешь? бедняша.
> и в чём проблема?В том что по большому счету мне этот крап там не сдался :)
> 54 /etc/shadow
Это ты что-то скромно - сделай wc -l экспорту реестра из винды, мальчик Билли покажет тебе что ты в вопросе засирaнии конфигурации всего лишь нуб позорный.
> ты что, каждый раз cat ему делаешь? бедняша.
Да вот знаешь, в винде меня как-то напрягал реестр. Хоть он и иерархически скомпонован, а как вылезет 100500 всяких CLSID нужных фиг знает для чего. Ну вот и 54 пользователя - туда же. На фоне этого поттер с его cgroups пожалуй не такой уж невменяемый чувак :)
это да. файл в 54 строчки — ужасно огромный объём данных. то-то я думаю: а чего это у меня техника так тормозит? а теперь понял: это она /etc/shadow ворочает. ужас.
p.s. так, для информации: я в курсе, откуда там взялся каждый пользователь и зачем он нужен.
Оно работает в андроиде только потому, что там все эти процессы по факту на ФС ни с чем, кроме своего каталога не взаимодействуют - всё идёт через андроидные API и его систему привилегий.
> Оно работает в андроиде только потому, что там все эти процессы по
> факту на ФС ни с чем, кроме своего каталога не взаимодействуют
> - всё идёт через андроидные API и его систему привилегий.что мешает выдавать привилегии в обычном линуксе?
> что мешает выдавать привилегии в обычном линуксе?Недостаточная гибкость системы привилегий на основе UID/GID.
>> что мешает выдавать привилегии в обычном линуксе?
> Недостаточная гибкость системы привилегий на основе UID/GID.какой гибкости вам конкретно не хватает? список! огласите весь!
Я не знаток, но, например, желание давать разрешение на форматирование вставленной флешки пользователю с текущим активным локальным сеансом для меня выглядит абсолютно логичным - и ни хрена не реализуемым в рамках только UID/GID - ну просто потому что динамика нужна. Если что - к сабжу это отношения не имеет и я понимаю, что в нём это, скорее всего, сделать нельзя.
> Я не знаток, но, например,udev это как-то делает , ну например udev может спросить, эй gdm? я не запущен ли прям сейчас какой юзер в систему ? а запущен? а запущен локально? а какой uid у юзера, а то в машину локально подрубили usb storage, дык может он ему нужен.
а потом через dbus сообщит менеджеру окон, дорогой незнакомец твой локальный юзер подрубил флэшку, я права на устройство выставил, можно читать, а если вдруг нужно замонтировать -- то воспользуйся наиболее подходящим для пользователя способом (policykit??)
Ну, например то, что андроидной системы привилегий в обычном линуксе нет (и правильно, там и так механизмов хватает).
Также то, что разработчики замахнулись не только на линукс и хотят использовать то, что везде уже есть. Хотя лично для меня подобный проект, написаный на плюсах под GPLv3 - и при этом пытающийся поддерживать *BSD выглядит как первоапрельская шутка.
> *BSD выглядит как первоапрельская шутка.в андроиде используется ядро с переписанной системой привелегий? чё правда?
> Мне одному кажется, что прибивать полномочия к путям файлов - идиотская идея?
> А если у нас не /usr/bin/X, а /usr/local/bin/X-experimental - тогда что?Тогда, очевидно, vdev не даст доступа.
Именно. Тут вот метки selinux поминали - вот это (или что-то подобное) было бы логичным решением. А по путям - костыль.
> Именно. Тут вот метки selinux поминали - вот это (или что-то подобное)
> было бы логичным решением. А по путям - костыль.спокуха, для путей регэкспы запилят. помяни мои слова.
Ну щас, начнут этот крап во FreeBSD юзать. Под GPL с FUSE и дырявым OpenSSL, ага.
> Ну щас, начнут этот крап во FreeBSD юзать. Под GPL с FUSE
> и дырявым OpenSSL, ага.Это было бы как раз в их духе. ZFS как-то так и приволокли. Даже копилефтность cddl не смутила :).
>> Ну щас, начнут этот крап во FreeBSD юзать. Под GPL с FUSE
>> и дырявым OpenSSL, ага.
> Это было бы как раз в их духе. ZFS как-то так и
> приволокли. Даже копилефтность cddl не смутила :).а потом ещё будут кичиться перед люниксоидами, что у них крутой вдев вместо глючного системдоса
Казалось бы, зачем ему OpenSSL? Шифровать ничего не надо же.
а, хешировать? в openssl таже md5 есть
Хмммм. Учитывая что в линухе сейчас ищут замену udev, имеет шансы на взлет
> Хмммм. Учитывая что в линухе сейчас ищут замену udev, имеет шансы на
> взлетКакой взлёт? Эта писанина на С++ с FUSE и SSL, чтоб создать файл устройства?! Смищьно!
> Какой взлёт? Эта писанина на С++ с FUSE и SSL, чтоб создать
> файл устройства?! Смищьно!Даже павлин два раза в сутки показывает время правильно :).
это гогно имеет шансы только умереть не рождённым.
> Хмммм. Учитывая что в линухе сейчас ищут замену udevПростите, что?
> Простите, что?Ну раз на великом и могучем не понимаете, напишу на мове. Вот как гугель перевел:
в linux зараз шукають заміну udev
Ищут пожарные, ищет милиция,
ищут давно но не могут найти.
Замену, замеру Гарри Поттеру.
Чтобы сказать куда ему пойти.
Хорошая идея, но должно быть как-то вроде что-то попроще. Даешь просто слой абстракции файловой системы. Что бы всякие fuse цеплялись разу к целому кусту. ПРостите за сравнение как обработчик HTTP запроса на определенном адресе ;-)
> обеспечивает контроль доступа на уровне процессовИ чо, переписывать все API? Ибо доступ к звуковухе немного иной,
чем к дискам и иной, чем к USB, и к /dev/tun, /dev/tun/tap, и к /dev/stdout
> на языке C++Тащить на столь низкий уровень проблемы C++ несколько странно.
Вы почитайте код. Там очень специфический C++. Ни единого класса.
> Вы почитайте код. Там очень специфический C++. Ни единого класса.Да, код там, фактически, на голом Цэ. Вопрос - зачем тащить проблемы ЦэПэПэ, как то: большая библиотека libstdc++, совершенно необязательная для UNIX-системы, нефиксированное ABI и т.д.?
Конечно, зачем может понадобиться std::vector. Все кто пишут менеджер девайсов, должны трахаться напрямую с malloc/free.
> Конечно, зачем может понадобиться std::vector.Ну да, и чтобы sha256 посчитать - припрем весь openssl. А если процесс понадобится запустить - так может не мелочиться и притащить весь системд сразу? :)
> чтобы sha256 посчитать - припрем весь openssl.На время девелопмента это - нормально. Такие микрооптимизации, как личный sha256 лучше относить "на потом"
> выступающего в роли кросс-платформенной и не зависящей от систем инициализации альтернативы udev и devfs. Работа vdev изначально тестируется не только в Linux, но и во FreeBSD и OpenBSD.А как же виндовс?
> код проекта написан на языке C++
Хорошо хоть не на Java. В общем автор этого гогна наверное сам поймёт что с ним делать.
>Код проекта написан на языке C++Надеюсь, на C++ w/o exceptions?
а вот в винде аналогичный функционал (\Device\<Name>) уже не менялся лет пятнадцать-двадцать и всё прекрасно работает. это только в линупсе любят менять шило на мыло ради самого процесса
> а вот в винде аналогичный функционал (\Device\<Name>) уже не менялся лет пятнадцать-двадцать и всё прекрасно работает.
> в винде
> всё прекрасно работает
> в винде
> работаетMade my day!
> и всё прекрасно работает.А что, винда уже научилась хотя-бы sata диск подцепленный на горячу монтировать без утонченных извращений со стороны юзера?
"В рамках проекта vdev развивается новая альтернатива devfs и udev "Может просто в systemD встроим и не будем париться? Напишу Поттерингу.
> Код проекта написан на языке C++вот до этих слов всё было так хорошо…
>> Код проекта написан на языке C++
> вот до этих слов всё было так хорошо…Код там - чистый C-style. Работа с памятью - malloc с free, char * вместо string и т.д. Нахрена зависимость от ++ добавили - вообще непонятно
да, каюсь, надо было таки самому посмотреть. просто меня два плюса в сочетании с «C» очень пугают, страшно глубже лезть.
трусиха
Пользуюсь eudev с лета, без проблем и нареканий!