LINUX.ORG.RU

kwin_wayland будет завязан на logind

 , , , ,


0

4

Мартин Грасслин, основной разработчик kwin, опубликовал в своей Google+ ленте сообщение, указывающее на дальнейшее развитие порта kwin на wayland. Вот полный текст сообщения:

Ломающие новости: kwin_wayland будет завязан на logind.

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

Да, kwin_wayland использует DBus интерфейсы, предоставляемые logind. Не потому, что я «специально» пытаюсь завязать его на systemd или что-то в этом роде, просто logind хорошо решает проблемы, которые сейчас стоят перед нами, и все другие варианты не обеспечивают нужную гибкость. Вам не нравится logind? Хорошо! Реализуйте совместимый интерфейс и kwin_wayland с удовольствием будет его использовать. Или же, если хотите, самостоятельно поддерживайте патчи, убирающие зависимость от logind.

Будет ли kwin_x11 использовать logind? Я думаю, нет, хотя Plasma 5 все глубже будет завязываться на logind. Опять же, это решает проблемы, неразрешимые другим путем. Например, если нужно программно отключить блокировщик экрана - в Plasma 5 это будет сделано через logind. Следовательно, если logind сможет решить какие-то проблемы для kwin_x11 - я буду его использовать.

<<конец сообщения>>

Таким образом, проект KDE следом за GNOME выбирает logind в качестве инструмента для управления пользовательской сессией, добавляя зависимость от systemd.

Оригинальный пост Мартина Грасслина

Перемещено leave из kde


Ответ на: комментарий от devl547

define велосипедность, примеры с пояснениями в студию... впрочем, давай хоть здесь очередной срач не разводить.

Вот Грасслин сказал, что logind решает те проблемы, которые ничто другое на данный момент не решает — значит, с большой степенью вероятности так и есть.

intelfx ★★★★★ ()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от King_Carlo

systemd превращает linux в такую же трудноподдерживаемую платформу как windows

почему наличие жирного ядра, поддержка которого для эникея практически невозможна, не превращает Линукс в венду, а systemd вдруг да?

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

logind решает те проблемы, которые ничто другое на данный момент не решает

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

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

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

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

полутора реалтеков

:)

Ну почитай его блог. Спроси, наконец. Я могу только догадываться, какого плана там возникли проблемы — или ты считаешь, что всё должно работать от рута, а все компьютеры в мире имеют одного пользователя и один терминал?

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

или ты считаешь, что всё должно работать от рута

Работа части софт от рута вообще не является проблемой.
Разграничение полномочий вообще не требует logind сотоварищи. Для этого есть проверенные временем варианты.

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

какого плана там возникли проблемы

Вот, наткнулся только что на красивую презенташку с GUADEC 2007, описывающую проблемы, которые должен был решать consolekit и сейчас решает logind: http://people.gnome.org/~mccann/talks/guadec-multiuser.pdf

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

Копай глубже. Кстати, я эту презенташку уже видел. Оверинжениринг и «сделаем как у конкурентов, только в разы хуже» как оно есть.

devl547 ★★★★★ ()
Последнее исправление: devl547 (всего исправлений: 1)
Ответ на: комментарий от devl547

Неужели pam? Или polkit? В линуксовых наслоениях для разграничения прав доступа довольно просто запутаться.

Вот, например, тебе надо запустить графический сервер от простого пользователя с прямым доступом к графическим ресурсам (KMS), как, по-своему, решается проблема? Через suid?

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

тебе надо запустить графический сервер от простого пользователя с прямым доступом к графическим ресурсам (KMS)

Сервер можно и от юзера запускать.
Один фиг с железом работают драйвера xf86-input-* и xf86-video-*.
Достаточно иметь юзера в нужной группе с доступом до устройств.

Неужели pam? Или polkit? В линуксовых наслоениях для разграничения прав доступа довольно просто запутаться.

Потому что оверинжениринг. Ну и все эти «мы не довели $somelib до ума, поэтому решили забить с нуля начать делать $somelib2, а потом $somelib3»
Энтерпрайз в этом деле нереально мешается под ногами. Потому что делают софт не для людей, а для себя.

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

Достаточно иметь юзера в нужной группе с доступом до устройств.

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

но при этом чтобы Xorg имел бы..

как-то так... :)

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

Не надо впадать в крайности

ну так вот и не впадай

а вот система инициализации и журналирования вполне себе понятна и полезна

спрошу прямо: сколько раз ты патчил инит?

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

ну так вот и не впадай

Я не впадаю, говорю как есть, не преувеличиваю.

спрошу прямо: сколько раз ты патчил инит?

Зачем?

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

Я не впадаю, говорю как есть, не преувеличиваю

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

Зачем?

перефразирую вопрос: что ты имеешь в виду под поддержкой инита?

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

systemd превращает linux в такую же трудноподдерживаемую платформу как windows

твои слова? расписывай

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

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

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

Ага, лол, он самый. В windows есть унифицированный системный слой утилит, сильно он облегчает поддержку? Унифицированный слой, если это слой дерьма, никак поддержку не облегчит, поддержка будет «унифицировано» покрыта слоем грабель.

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

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

xkcd://15 стандартов

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

В windows есть унифицированный системный слой утилит, сильно он облегчает поддержку?

да

Унифицированный слой, если это слой дерьма, никак поддержку не облегчит, поддержка будет «унифицировано» покрыта слоем грабель.

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

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

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

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

ещё одна блондинка закукарекала

когда я пропустил момент, когда люди начали не стыдиться своей тупости, а хвастливо выпячивать её напоказ?

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

capabilities? Я как-то забыл про них. На почитай: https://forums.grsecurity.net/viewtopic.php?f=7&t=2522 Версия для Ъ:

current Linux security architecture is quite a mess.

Вот еще нашел обсуждение по xorg-server capabilities: https://bugs.archlinux.org/task/26682, решили что ненужно:

I don't see much of a difference between giving a process CAP_DAC_OVERRIDE/CAP_SYS_ADMIN and running as root.

mtk ()
Последнее исправление: mtk (всего исправлений: 1)
Ответ на: комментарий от mtk

current Linux security architecture is quite a mess.

внутри ядра всё работает через capabilities

Вот еще нашел обсуждение

это какие-то клоуны писали, учитывая что xorg спокойно работает от обычного пользователя без привилегий

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

В /usr/bin/Xorg выставлен suid бит почти во всех дистрах, нэ?

это какие-то клоуны писали

Пока что клоуном выставляешь себя ты.

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

На почитай:

почитал, сводится «к кокок у рута уже все привелегии ядра потому capabilities не работают». и к чему это

Пока что клоуном выставляешь себя ты.

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

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

В /usr/bin/Xorg выставлен suid бит почти во всех дистрах, нэ?

и что

и не во всех:

$ equery uses xorg-server
...
 - - static-libs : Build static versions of dynamic libraries as well
 - - suid        : Enable setuid root program, with potential security risks
 - - systemd     : Enable use of systemd-specific libraries and features like socket activation or session tracking
...

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

От того, что suid не выставлен, иксы, запущенные от рута становятся ненамного секурней (особенно с монструозными display manager'ами навроде gdm или kdm).

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

xorg спокойно работает от обычного пользователя без привилегий

чё-то ты совсем зазвизделся, трепло собачье

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

покажи, сучка, где они работают

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

тебе есть что на это возразить, кроме что «в в рачлинуксе стартует от рута, значит не может»

я знаю о чём говорю, в отличии от тебя

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

xorg-server<1.16.0 работает только от рута или с достаточным набором capabilities, некоторые из которых (CAP_SYS_ADMIN) почти то же самое что рут (в ссылке на форум grsecurity объяснено почему). Есть возражения?

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

Ну ОК, я всегда открыт для новых знаний, особенно полученных от достопочтенного анонимуса.

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