Не многовато ли для замкнутости?

Не многовато. Всё это либо D-Bus, либо функции «базовой платформы» (хз как еще назвать системные Си-библиотеки), для общения с которой COM не нужен.

COM был нужен MS для создания экосистемы _сторонних разработчиков приложений_. И вот такой экосистемы у Linux и близко нет, из-за отсуствия COM или самих разработчиков - ХЗ. Наверное, здесь заколдованный круг.

http://forum.kde.org/viewtopic.php?f=43&t=90392

на случай чего?

Кто ж знает, что с виндой случиться может.

ничего с ней не случится

Близзард только твоими обещаниями и живёт.

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

А при чём тут смерть винды? Ути, толстячок.

Тебе устройство ELF мешает использовать номера версий в именах библиотек? Да ты талант!

Не-не-не, дэвид. Мы же не плагины обсуждаем, так что давай по-спортивному.

Это как раз ты пересокочил с обеспечения совместимости со старыми интерфесами на принятие решения в рантайме о прогрузке интерфейса.

Если у нас есть СТАРЫЙ интерфейс (не поддерживаемый в системе), без которого программа НЕ РАБОТАЕТ, то никакой разницы нет, что это — имя разделяемого модуля или имя COM-интерфейса. Потому что программа всё-равно НЕ РАБОТАЕТ.

И какое отношение этот лисапед с квадратыми колёсами имеет к спецификации трея, лежащей на fd.o?

Если у нас есть СТАРЫЙ интерфейс ... то никакой разницы нет, что это — имя разделяемого модуля или имя COM-интерфейса.

Разница в том, что новая реализация точно знает, какой именно интерфейс требует старое ПО и теоретически имеет возможность его эмулировать, как это, скажем, сделали в alsa для oss. Это, разумеется, не означает, что эмуляция будет всегда и везеде, и что эта волшебная вундерфаля спасёт мир. Но шансы возрастают.

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

Этот лисапед с квадратыми колёсами на д-басе заменяет лисапед с треугольными колёсами на иксовом протоколе, который обеспечивает то, что в венде называется «tray tooltip».

Разница в том, что новая реализация точно знает, какой именно интерфейс требует старое ПО и теоретически имеет возможность его эмулировать, как это, скажем, сделали в alsa для oss. Это, разумеется, не означает, что эмуляция будет всегда и везеде, и что эта волшебная вундерфаля спасёт мир. Но шансы возрастают.

И что ж тебе, дурню, мешает проэмулировать /lib/liboldapi.so.3 поверх /lib/libтуцapi.so.1? Ну кроме лени, разумеется.

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

Бугагашечки. И что помешает скайпу, ЗНАЯ о существовании нового API, продетектировать его наличие, и точно также обломать всю малину? Ничего не помешает.

Этот лисапед с квадратыми колёсами на д-басе заменяет лисапед с треугольными колёсами на иксовом протоколе, который обеспечивает то, что в венде называется «tray tooltip».

Прекрасный пример идиотизма современных «разработчиков», которые не осилили прочитать спецификацию, на которую ссылаются. Ни они не осилили, ни ты не осилил.

Balloon messages

Tray icons may ask the system tray to display a balloon message to the user. The system tray coordinates balloon messages to ensure that they have a consistent look-and-feel, and to avoid displaying multiple balloon messages at once.

A balloon message is a short text message to be displayed to the user. The message may have a timeout; if so, the message will be taken down after the timeout expires. Messages are displayed in a queue, as only one can appear at a time; if a message has a timeout, the timer begins when the message is first displayed. Users may be allowed to close messages at any time, and may be allowed to disable all message display.

System trays may display balloon messages in any way they see fit; for example, instead of popping up a balloon, they could choose to put a special indicator around icons with pending messages, and display the message on mouseover.

Balloon messages are sent from the tray icon to the system tray selection owner window as a series of client messages. The first client message is an opcode message, and contains the usual timestamp, and the op code SYSTEM_TRAY_BEGIN_MESSAGE. xclient.data.l[2] contains the timeout in thousandths of a second or zero for infinite timeout, xclient.data.l[3] contains the length of the message string in bytes, not including any nul bytes, and xclient.data.l[4] contains an ID number for the message. This ID number should never be reused by the same tray icon. (The simplest way to generate the ID number is to increment it with each message sent.)

Following the SYSTEM_TRAY_BEGIN_MESSAGE op code, the tray icon should send a series of client messages with a message_type of _NET_SYSTEM_TRAY_MESSAGE_DATA. These client messages must have their window field set to the window ID of the tray icon, and have a format of 8.

Each _NET_SYSTEM_TRAY_MESSAGE_DATA message contains 20 bytes of the message string, up to the length given in the SYSTEM_TRAY_BEGIN_MESSAGE opcode. If the message string is zero-length, then no messages need be sent beyond the SYSTEM_TRAY_BEGIN_MESSAGE. A terminating nul byte should never be sent.

System trays may receive portions of messages from several tray icons at once, so are required to reassemble the messages based on the window ID of the tray icon.

The tray icon may wish to cancel a previously-sent balloon message. To do so, it sends a SYSTEM_TRAY_CANCEL_MESSAGE opcode with data.l[2] set to the ID number of the message to cancel. 

На мыло всех.

блин

s!/lib/libтуцapi.so.1!/lib/libnewapi.so.1!

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

А именно: никак.

Для разработки этого протокола не было вообще никаких технических оснований. (При том что он еще и по фичам слабее.) Тем не менее, он не просто создан, но и «is aimed as a replacement to the Freedesktop System tray specification».

И никакой COM тут не поможет.

Бугагашечки. И что помешает скайпу, ЗНАЯ о существовании нового API, продетектировать его наличие ...

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

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

Давай, расскажи как ld.so весь обтянутый в трико и с развевающимся плащём за спиной стремительно врывается в эту кулстори и спасает скайп (и его пользователей) от геммороя.

Тем не менее, он не просто создан, но и «is aimed as a replacement to the Freedesktop System tray specification».

Проснись и пой, он уже используется несколько лет:

anon@nimous:~$ dbus-monitor  | grep -A10 -B5 test
method call sender=:1.59 -> dest=org.freedesktop.Notifications serial=13 path=/org/freedesktop/Notifications; interface=org.freedesktop.Notifications; member=Notify
   string "mate-notification-properties"
   uint32 0
   string "dialog-information"
   string "Notification Test"
   string "Just a test"
   array [
   ]
   array [
   ]
   int32 -1
method call sender=:1.70 -> dest=org.freedesktop.DBus serial=30 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch
   string "type='signal',sender='org.mate.ScreenSaver',path='/',interface='org.mate.ScreenSaver'"
method call sender=:1.70 -> dest=org.freedesktop.DBus serial=31 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch
   string "type='signal',sender='org.freedesktop.DBus',path='/org/freedesktop/DBus',interface='org.freedesktop.DBus',member='NameOwnerChanged',arg0='org.mate.ScreenSaver'"

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

Внезапно, есть стандартный аудио-API - libalsa. Есть даже эмуляция oss поверх alsa. Но этой эмуляции может не оказаться на конкретной машине, и никакая доза COM с этим ничего не сделает.

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

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

Если бы модуль осс был бы *гарантированной* частью интерфейса альсы, всех этих проблем бы не было.

Тебе ничего не мешает безо всякого COM заставить разрабов объявить его *гарантированной* частью интерфейса альсы. Упс. На самом деле мешает — ты ведь им не начальник, и ты им не платишь ни копейки за работу. И никакой COM тут ни при чем.

Давай, расскажи как ld.so весь обтянутый в трико и с развевающимся плащём за спиной стремительно врывается в эту кулстори и спасает скайп (и его пользователей) от геммороя.

Давай, я тебе лучше расскажу, как какой-нибудь IOSSProvider весь обтянутый в трико стремительно врывается в эту кулстори и получает с разбегу в лоб ERROR_INTERFACE_NOT_IMPLEMENTED. А всё потому что описываемые тобой «проблемы» (хотя на самом деле конечно никакие не проблемы) лежат в административной, а не в технической плоскости. Чего вы вместе со Стиви никак не можете осознать второй день.

Проснись и пой, он уже используется несколько лет:

Я прекрасно знаю, что он используется. Что абсолютно не делает эту нелепую поделку хоть сколько-нибудь полезной или нужной, т.к. никаких проблем старого протокла оно не решало. Просто кто-то сильно страдал от NIH-синдрома, вот и всё.

Внезапно, есть стандартный аудио-API - libalsa.

Внезапно, до этого стандартным аудио-API был OSS.

Но этой эмуляции может не оказаться на конкретной машине

О чём и поинт.

никакая доза COM с этим ничего не сделает.

Дело не в конкретном COM'е - уж тыщу раз говорено. Дело в *публичном двоичном интерфейсе*. ABI, если угодно. Бох с ними, с разработчиками, возьмём дистростроителей. Какой из дистров имел однозначную политику по вопросу замены OSS на alsa? Кто из них заявил о поддержке oss-api до N-ого года, кто дал границы переходного периода для софта с oss на alsa? А если время жизни API не известно - какой смысл инвестировать в разработку софта под этот API?

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

достаточно виртуалки.

Недостаточно. Оценить, насколько, сцуко, оно шустрое стало, можно только вживую :)

COM был нужен MS для создания экосистемы _сторонних разработчиков приложений_.

Однако в основном эта «экосистема» свелась к встраиванию объектов сторонних разработчиков в мсворд.

Ну, к примеру, в восьмерке проблематично найти кнопку выключения

Я сразу увидел. Ещё в Linux/Compiz привык по углам тыкаться :)

Кто-то где-то говорил, что достаточно запилить ком (кстати, зачем, если есть D-BUS ?) и наступит коммунизм?

Наступит COMmunism :)

Если в раму суспендить - то заряд тратится

Ужасы какие-то. Крышку закрыл, сутки спустя открыл, заметного разряда не видно. А если на месяц нужно вырубать, тогда — да, можно и выключить. Но это очень редкий случай.

у них есть универсальная WM+DE - metro

Оно уже ни в коем случае не Metro. Было официальное внутреннее указание нигде не использовать это название. Срочно ищут новое. А пока — условно Windows 8 Style GUI или что-то в это духе, дословно не помню :)

В кои-то веки новая виндовс работает быстрее предыдущей, что уже само по себе вин

Это уже много раз было. WinME работала быстрее, чем Win98, Win 7 работает быстрее, чем Win Vista, WM6 работала быстрее, чем WM5. На хорошем железе XP работает быстрее, чем 2K.

Всё правильно — старые API надо выпиливать, чтобы они не мешали развитию.

Какому «развитию», дурень? Троекратное переписывание гнома - это ты называешь «развитием»? Или двукратное кед? Где твоё «развитие» - покажи мне его?

А то, что скайп криво написан — так это личные половые трудности его разработчиков.

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

Я прекрасно знаю, что он используется.

Да ты не знал о его существовании, пока я не дал тебе ссылку.

WinME работала быстрее, чем Win98

4.2, а в остальном всё верно.

Работать медленнее, чем вин7 уже невозможно.

Вот так палятся люди, не видившие Win Vista :) Да и что касается чистого GUI, то под той же Ubuntu всё медленнее...

WinME работала быстрее, чем Win98

4.2, а в остальном всё верно.

В ME сделали (провалившуюся) попытку выкинуть ядро DOS (вынеся в VM), из-за чего ME жрала меньше памяти и грузилась в аккурат вдвое быстрее (на тогдашнем моём железе за 20 секунд вместо 40 у 98).

У тебя либастрал криво собран, дурень.

Бох с ними, с разработчиками, возьмём дистростроителей. Какой из дистров имел однозначную политику по вопросу замены OSS на alsa? Кто из них заявил о поддержке oss-api до N-ого года, кто дал границы переходного периода для софта с oss на alsa? А если время жизни API не известно - какой смысл инвестировать в разработку софта под этот API?

Дистростроители не могут дать такие гарантии, потому что не они всё это разрабатывают. Не надо ставить организациооно на одну ступеньку, скажем, MS, Apple и Debian.

Я щас не скажу про скорость загрузки/объем потребления, но пользователькие приложения под 98SE работали ощутимо быстрее. В ME, емнип, нельзя было отключить актив десктоп, что давало заметные тормоза для гуйни.

В ME, емнип, нельзя было отключить актив десктоп

Ну, тут фиг знает, я к тому времени 98 использовал со всеми эффектами :)

Дистростроители не могут дать такие гарантии

А как же опенсорс ?!?!? Ведь он же опен !!11111

Не придуривайся.

Ну а я вот использовал 98 без всяких эффектов, пока не был вынужден пересесть на xp sp1. )) Хотя тот факт, что хр работает ощутимо быстрее 2к, несколько подсластил пилюлю.

Хотя тот факт, что хр работает ощутимо быстрее 2к, несколько подсластил пилюлю.

Но, повторюсь, только на достаточно толстых машинах. Например, на 64Мбайт, ОЗУ 2K работала заметно быстрее. Памяти меньше потребляла. А вот GUI у неё был тормознее. И грузилась НАМНОГО дольше (в XP впервые задействовали параллельную загрузку сервисов).

Я сразу увидел. Ещё в Linux/Compiz привык по углам тыкаться :)

Ну вот, а я после xmonad ;)

COM был нужен MS для создания экосистемы _сторонних разработчиков приложений_.

Однако в основном эта «экосистема» свелась к встраиванию объектов сторонних разработчиков в мсворд.

ЩИТО? Такое впечатление, что ты занимался конторской автоматизацией. Даже я за неполных 2 года работы в венде успел столнуться с кучей ActiveX и компонентов доступа к СУБД (нет, в MS Word они не встраивались).

Дело не в конкретном COM'е - уж тыщу раз говорено. Дело в *публичном двоичном интерфейсе*. ABI, если угодно.

Чтобы этот ABI был полезен, за ним должен быть код. А его нет.

дос, сцуко, тоже шустрый, вот только не юзабельный. как и вин8.

дос, сцуко, тоже шустрый, вот только не юзабельный. как и вин8.

А что в последнем неюзабельного в сравнении с той же Win 7? Да и хоть с Ubuntu же?

Чтобы этот ABI был полезен, за ним должен быть код. А его нет.

Так потому и нет, что соблюдение ABI не рассматривается ни кем как цель, и даже в тех случаях, когда такой код есть (oss-compat), дистроклепатели норовят побырому замести его подковрик. Вот и имеем «развитие» вместо развития.

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

WinME работала быстрее, чем Win98

неа :(