LINUX.ORG.RU
ФорумTalks

[апокрифические чтения]Готов для десктопа


0

2

Давно хотелось поднять тему того, как священные принципы Unix гниют и разлагаются под тяжестью новых сущностей в виде протоколов, api и прочего мусора.
Но написать больше и лучше, чем Tonnerre Lombard, вряд ли получится, поэтому предлагаю почитать оригинал.

The destructive desktop — Linux in trouble?

Linux on the desktop has come a long way. The Gnome and KDE communities have built themselves a big, very powerful set of tools to build on. And using these tools, they created an enormous amount of software for a large number of different purposes.

Then they discovered that there is a lack of formality in the RPC mechanisms available under UNIX like operating systems. The Shared Memory IPC provides just shared memory and a little flow control, which is tedious. The sysvmsg API is still very inconvenient when communicating between various different processes, especially if they're arbitrary. Sockets work much better in that respect and have a well-defined API, but it is still relatively hard to exchange data over them.


http://blog.ngas.ch/archives/2011/12/13/the_destructive_desktop__mdash_linux_...

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

★★★★★

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

Пропустил:

Какой она должна быть

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

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

Там Bonjour, Avahi — это другая реализация.

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

Мне — пока ничего, но это не важно. Важно искусственное ограничение области применения.

Где ты видишь искусственное ограничения области применения?

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

Т.е. программа, увеличивающая прозрачность

Архитектурно всё наоборот, а что пользователю стало жить проще — то само собой.

Я так понимаю на то, что автор статьи имеет существенные проблемы с матчастью, возражений нет?

Конечно нет. А поскольку лично ты никогда не спутаешь de с wm, то ты конечно во всём прав. Возражений нет?

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

Там написано, что нужда в вещах вроде PA возникла благодаря бардаку со звуковым api, pa нам добавил ещё один слой.

Как сказано по ссылке и уже сказал здесь geekless, нужда в PA существовала. Потому он и возник.

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

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

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

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

На сайте Avahi написано, что Avahi поддерживает и OS X

А, пардон, был не в курсе.

Где ты видишь искусственное ограничения области применения?

Это камень скорее в огород systemd, портировать сетевые программы всяко проще, если будет надобность.

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

Это камень скорее в огород systemd

systemd создан для оптимизации процесса загрузки Linux. Он остался совместим со всем тем, что было до него => может быть заменен легко портабельными, но не оптимизированными под Linux альтернативами.

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

Архитектурно всё наоборот

Было:
1. Прибитый в ядро OSS.
2. Прибитый к собственным библиотекам и ядру ALSA.

Стало:
Кросплатформенный звуковой сервер, работающий в виде отдельного процесса и умеющий:
* Раздельно регулировать громкость каналов.
* Произвольно подключать любые источники звука к любым устройствам воспроизведения.
* Передавать звук по сети.
* Использоваться с существующим софтом, не требуя переписывания оного, благодаря наличию модулей перенаправляющих звука в PA.

Доо, раньше-то конечно лучше было: API звука, сам не перепишется, перепиши его, перепиши его еще раз! А потом прибей гвоздями к платформе!

По факту, PA устранил вопиющее нарушение юниксвея в звуковой подсистеме юниксов.

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

а что пользователю стало жить проще — то само собой.

Т.е. когда пользователю жить проще, это плохо, а когда наоборот — это хорошо? Померь температуру, у тебя наверняка жар.

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

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

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

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

Поздравляю с переходом на правильную сторону Силы :)

Я-то на правильной, а вот вы оба — нет.

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

По факту, PA устранил вопиющее нарушение юниксвея в звуковой подсистеме юниксов.

Он просто абстрагировался от этого бардака, но ничего не устранил.

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

Так и запишем: aidaho считает, что смешивать в кучу низкоуровневые и высокоуровневые API, а также юзать ПО, решающее кучу задач сразу — это юниксвейно. Не так?

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

Так и запишем: aidaho считает, что смешивать в кучу низкоуровневые и высокоуровневые API, а также юзать ПО, решающее кучу задач сразу — это юниксвейно. Не так?

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

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

Вообще ты по существу будешь говорить или нет?

Ты понимаешь, что ыт сейчас делаешь? Ты начитался какой-то статьи и повторяешь: «PA плохой», «PA не юниксвейный», «PA выпьет ваш мозг и съест ваших детей».

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

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

Ты понимаешь, что ыт сейчас делаешь?

Да, franchuckroman увидел слово «Поттеринг» и втянул меня в бесполезный срач. На PA мне вообще пофиг, о чём я уже несколько раз упомянул, но вы вдвоём настойчиво хотите об этом поговорить.

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

Спасибо за чёрнобелый роадмап.
PA прикрывает бардак в звуковой подсистеме (вспоминаем про рыбу), закапывая стимулы что-то исправлять. PA, как и многие другие, использует неюниквейный dbus.

aidaho ★★★★★
() автор топика

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

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

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

PA прикрывает бардак в звуковой подсистеме

В звуковой подсистеме всё в порядке. Есть кросплатформенный звуковой сервер. Есть платформоспецифичный движок ввода-вывода звука на реальные устройства. Всё хорошо.

PA, как и многие другие, использует неюниквейный dbus.

Это ж жесть какая-то. Скажи, ты пробовал разобраться в вопросе, прежде чем писать? Давай я тебе помогу. Открываем страницу http://pulseaudio.org/wiki/DownloadPulseAudio#Requirements и читаем в списке зависимостей: «DBus-GLib 0.7.x (optional)».

Это было во-первых. Теперь во-вторых. То, что dbus неюниквеен, автор опуса высосал из пальца. Ах, у него там интерфейсы программ меняются с каждым релизом! Ой-ёй-ёй, какие нехорошие. А кто виноват, dbus виноват? Или может всё-таки авторы тех программ, где корёжат интерфейсы? Давай подумаем. Если завтра у cp начнёт меняться интерфейс вызова, кто будет виноват — разработчик cp или разработчик шелла, через который ты cp запускаешь? «bash не юниксвеен!» — гордо напишет наш автор.

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

Ладно, пошел я спать. Флудите без меня тут, со второй макакой.

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

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

Когда это принципиальные виндузятники успели попасть в красную книгу???? :-)

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

Я же сказал: на _человеческом_ :)

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

Это ж жесть какая-то. Скажи, ты пробовал разобраться в вопросе, прежде чем писать?

Разобраться в PA? Нет.

читаем в списке зависимостей: «DBus-GLib 0.7.x (optional)

И как потом сторонние фронтенды будут им управлять? С портированием dbus на всякие bsd, как пишет нам автор, возникли проблемы, хоть он и заявлен как posix-совместимый

То, что dbus неюниквеен, автор опуса высосал из пальца. Ах, у него там интерфейсы программ меняются с каждым релизом! Ой-ёй-ёй, какие нехорошие. А кто виноват, dbus виноват? Или может всё-таки авторы тех программ, где корёжат интерфейсы?

В этом случае — авторы. cp выругается, а с dbus всё менее очевидно.

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

POSIX тоже абстрагировал от железа, но не устранил проблему невозможности написания железонезависимого софта, да?

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

PA прикрывает бардак в звуковой подсистеме

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

PA, как и многие другие, использует неюниквейный dbus.

Чем он неюниксвейный?

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

Так к модульности, значит, претензий нет?

Да, оставим эту тему.

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

С портированием dbus на всякие bsd, как пишет нам автор, возникли проблемы, хоть он и заявлен как posix-совместимый

http://www.freebsdsoftware.org/devel/dbus.html - DBus в FreeBSD

http://openports.se/x11/dbus - DBus в OpenBSD

ftp://ftp.netbsd.org/pub/pkgsrc/current/pkgsrc/sysutils/dbus/README.html - DBus в NetBSD

http://www.opencsw.org/packages/dbus/ - DBus для сорлярки (и в Nexenta тоже есть DBus)

Для Mac OS X можно поставить через macports или homebrew

Для венды есть экспериментальная сборка.

Так что, ты говоришь, с портированием?

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

Чтобы не быть голословным:

http://code.google.com/p/dbus-windows-installer/downloads/list

http://sourceforge.net/projects/windbus/

Это даже не POSIX-совместимая злоОС. И та умеет DBus.

Ну и пруф на макпортс относительно поддержки маком: https://trac.macports.org/browser/trunk/dports/devel/dbus/Portfile

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

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

Это абстракция от ОС, какие проблемы она маскирует?

Чем он неюниксвейный?

Опять возвращаемся к статье?

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

The problem is that even users of FreeBSD and NetBSD want to use some of the software which was implemented for one of the desktop environments will have to find ways to make the DBus services work and react in the correct way. Jared McNeill attempted this with the NetBSD port of DeviceKit, but most operating systems aren't designed to support the kind of APIs involved. As a result, it becomes extremely difficult to support such software, and makes all operating systems more like Linux if they want to be able to run this type of software.

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

Это абстракция от ОС, какие проблемы она маскирует?

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

Опять возвращаемся к статье?

Так ты скажешь, чем он неюниксвейный или нет?

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

Нудк к ОС прибит DevKit. Где тут виноват DBus? А DBus отлично работает на всех перечисленных платформах и юзабелен даже на неродной ему венде.

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

Нудк к ОС прибит DevKit. Где тут виноват DBus?

devicekit, policykit, consolekit, dbus (и ещё куча всего) — это всё части freedesktop, который, напоминаю, декларирует своей целью стандартизацию posix-десктопа. Постепенно оказывается, что posix-desktop = linux-desktop.

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

Википедия:

DeviceKit — модульный HAL, предназначенный для использования в системах Linux, чтобы упростить управление устройствами и заменить текущий монолитный Linux HAL.

Т.е., Devkit - изначально Linux-only. А сейчас Devkit расформировали, и образовалось несколько отдельных компонентов (udisks, upower и т.д.), завязанных чисто на udev (который Linux-only).

Так а какие претензии к портабельности DBus? А то съезжаешь с темы :)

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

Так ты скажешь, чем он неюниксвейный или нет?

Попробуй доказать его юниксвейность в присутствии, к примеру ipv6 local multicast. Напомню, у последнего варианта плюсы вроде сетевой прозрачности, отсутствия лишних сущностей, богатого инструментария для манипуляций и отладки.
Что есть у dbus? Перегруженное пространство (никому не нужных) имён?

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

Так а какие претензии к портабельности DBus?

Проблема не в dbus, как в сервисе, а в том, что число перекрёстных зависимостей среди приложений, его использующих, достигло того уровня, что с портируемостью начались проблемы.
Т.е. к примеру, policykit хочет consolekit, consolekit хочет dbus, приложение хочет policykit и т.д. Теперь всё это портировать ради одного десктопного приложения?
Сам по себе dbus хоть на луну можно послать, благо он не нужен.

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

Попробуй доказать его юниксвейность в присутствии, к примеру ipv6 local multicast

С каких это пор IPv6 local multicast заделался RPC?

Что есть у dbus?

КО: DBus - это RPC, и сравнивать его с ipv6 local multicast - некорректно.

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

Сам по себе dbus хоть на луну можно послать, благо он не нужен.

Альтернативы? DCOP мертв (и шило на мыло). Большинство остальных либо мертвы, либо нишевые.

Проблема не в dbus, как в сервисе, а в том, что число перекрёстных зависимостей среди приложений, его использующих, достигло того уровня, что с портируемостью начались проблемы.

Каким образом в этом виноват сам DBus? Каким боком он вообще относится к перекрестным зависимостям приложений, которые его используют?

Т.е. к примеру, policykit хочет consolekit, consolekit хочет dbus, приложение хочет policykit и т.д. Теперь всё это портировать ради одного десктопного приложения?

Это все портировано везде, куда нужно. А вообще, простым десктопным приложениям, помимо некоторых утилит, PolicyKit не нужен, поэтому в зависимостях его быть не должно. Но каким боком тут DBus?

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

Разобраться в PA? Нет.

Т.е. и вещах, о которых ты берешься судить, ты не разбираешься. Откровенно.

И как потом сторонние фронтенды будут им управлять?

Какие еще «сторонние фронтэнды»? Соединение клиента с сервером PA осуществляется через сокет. Программный интерфейс находится libpulse.

С портированием dbus на всякие bsd, как пишет нам автор, возникли проблемы, хоть он и заявлен как posix-совместимый

facepalm.xml

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

Проблема не в dbus, как в сервисе, а в том, что число перекрёстных зависимостей среди приложений, его использующих, достигло того уровня, что с портируемостью начались проблемы.

Сам по себе dbus хоть на луну можно послать, благо он не нужен.

Проблема не в POSIX, как в сервисе, а в том, что число перекрёстных зависимостей среди приложений, его использующих, достигло того уровня, что с портируемостью начались проблемы. Сам по себе POSIX хоть на луну можно послать, благо он не нужен. :-D

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

Потсоны, ваш диалог реально взрывает мозг. Нужно сделать на сайте systemd отдельный раздел, рядом с Q&A, назвать его «домыслы и предубеждения», и скопипастать этот диалог туда целиком.

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

PA

Чем знаменит? Чем лучше oss?

Тем, что работает, а не требует идиотизма с убийством любого юзающего звук приложения при всего лишь s2ram/s2disk.

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

С каких это пор IPv6 local multicast заделался RPC?

В статье предлагалось использовать sunrpc, который работает как раз через сетевой стек.

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

Тем, что работает, а не требует идиотизма с убийством любого юзающего звук приложения при всего лишь s2ram/s2disk.

А это где такие порядки? С alsa без прослоек сколько суспендил со звуком, проблем не помню.

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

а не требует идиотизма с убийством любого юзающего звук приложения при всего лишь s2ram/s2disk.

Вот чего не знаю, того не знаю. Единственная ОС, на которой я юзал саспенд (OpenBSD) обладает своей реализацией OSS (кстати, linux'овая реализация - ядерная -это не ossv4), в которой при саспенде ничего убивать не надо было.

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

кстати, linux'овая реализация - ядерная -это не ossv4

Ядерная линуксовая это deprecated говно мамонта, которая не дотягивает и до alsa.

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