Blizzard тоже недоволен Win8

~0.36 ватт в час, да, не так уж и много.

Второй раз в треде вижу «ватты в час». Что это?? Вт*ч - это энергия, Вт - это мощность, а Вт/ч - это что?

Количество ватт, потребляемых в час. Разве это не очевидно?

Правильно измерять, сколько потреблялось ёмкости аккумулятора в час. Ёмкость измеряется либо в мАч, либо в Вт/ч.

Кипятильник потребляет 1 кВт. Не в час - просто кВт. Или 1000 джоулей энергии за одну секунду. В час он потребляет 3,6 МДж энергии. 1 ватт в час - это больше или меньше?

Правильно измерять, сколько потреблялось ёмкости аккумулятора в час. Ёмкость измеряется либо в мАч, либо в Вт/ч.

Там криво написано. Но думаю все поняли о чем я.

(пожимая плечами) Ну совмести мне обратно модули какого-нибудь нетфильтра с 2.6.23 с 2.6.26

Утипути. А давай возьмем никому нафиг не нужный freevxfs:

$ git diff -r v2.6.12 -r v2.6.39 freevxfs | diffstat
 b/fs/freevxfs/Kconfig       |   16 +++++++
 b/fs/freevxfs/vxfs.h        |    7 +--
 b/fs/freevxfs/vxfs_bmap.c   |    5 +-
 b/fs/freevxfs/vxfs_dir.h    |    4 -
 b/fs/freevxfs/vxfs_extern.h |   17 +++++--
 b/fs/freevxfs/vxfs_fshead.c |   25 +++++------
 b/fs/freevxfs/vxfs_immed.c  |   17 ++++---
 b/fs/freevxfs/vxfs_inode.c  |   96 ++++++++++++++++++++++++--------------------
 b/fs/freevxfs/vxfs_lookup.c |   34 ++++++---------
 b/fs/freevxfs/vxfs_olt.c    |   20 ++++-----
 b/fs/freevxfs/vxfs_olt.h    |    2 
 b/fs/freevxfs/vxfs_subr.c   |   11 -----
 b/fs/freevxfs/vxfs_super.c  |   57 +++++++++++++++-----------
 fs/freevxfs/vxfs_kcompat.h  |   49 ----------------------
 14 files changed, 169 insertions(+), 191 deletions(-)
$

Ну и где он переписан?

Недавно собирал тулчейн для 2.6.22 с glibc-2.5, gcc 4.6.3 и прочим новым стаффом

Собери MSVC и MSVCRT.dll для XP новым MSVC и сообщи, как оно пройдет.

А исходный код - один из столпов обратной совместимости в Linux.

Как ни парадоксально, вовсе нет.

Бред.

Если меняется API и софтину некому поддерживать - софт идёт в помойку.

А если софтину есть кому поддерживать - она продолжает жить.

Чем действительно хорош com - это публичный двоичный api, и сделан он был МС как раз для того, чтобы можно было прозрачно менять реализацию интерфейса

Ну ладно stevejobs - он, может, и правда не понимает цены этого, но ты? Значит, тупо троллишь.

А давай возьмем никому нафиг не нужный freevxfs

И как я должен интерпретировать этот стат? Там же английским по синему написано что фиксили (если исходить из того, что он нафиг не нужен и фиксы не по делу).

А мы тут еще в рамках >=2.6.9 болтаемся, которому лет меньше чем XP.

Собери MSVCRT.dll для XP новым MSVC и сообщи, как оно пройдет.

Зачем я буду это делать? Там никто не заявлял о совместимости исходными кодами

И как я должен интерпретировать этот стат?

Как то, что слова

vasily_pupkin> Нет никакой обратной совместимости с исходным кодом. Особенно в линаксе. Ну если конечно обратная совместимость это не «взять и переписать».

являются ложью. Заведомой ложью, принимая во внимание твой бэкграунд.

Зачем я буду это делать?

Для сравнения.

Там никто не заявлял о совместимости исходными кодами

Бгг.

Тебе слово переписать не понравилось что ли? Ну дописать, ок )) Переписать - это про 2.4->2.6.

Но от этого ничего не меняется. Для синка с апстримом код надо фиксить. Это говно, а не совместимость.

Тебе слово переписать не понравилось что ли?

Именно.

Но от этого ничего не меняется.

Перестань притворяться кретином.

Для синка с апстримом код надо фиксить. Это говно, а не совместимость.

Если тебя не устраивает степень совместимости - сделай лучше или мигрируй туда, где сделали лучше.

Ну ладно stevejobs - он, может, и правда не понимает цены этого, но ты? Значит, тупо троллишь.

Вот тебе реальный пример того, как сама МС использует этот интерфейс - диалог открытия/сохранения файла. Этот диалог - COM-объект. Во всех версиях венды этот диалог реализован по-разному, а в тертьем сервиспаке для XP его заменили на новый, т.е. он разный даже в рамках одной «мажорной» версии ОС.

Причём этот com-интерфейс используется для внутренней кухни самой МС, для клиентских приложений он доступен через winapi-вызовы GetOpenFileName и GetSaveFileName.

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

[реклама COM поскипана]

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

Ты скажи. Заодно объясни, почему данный пример не реализуем просто как API динамической библиотеки.

http://habrahabr.ru/post/147002/

Ты скажи.

Так это и есть ответ на вопрос:

Заодно объясни, почему данный пример не реализуется просто как API динамической библиотеки.

Потому что нет привязки к реализации на уровне двоичного образа процесса до момента использования. В реализации можно хоть конём скакать, хоть дотнет запустить. Это средство обеспечения гетерогенности.

почему данный пример не реализуется просто как API динамической библиотеки.

Потому что нет привязки к реализации на уровне двоичного образа процесса.

Если COM-сервер запускается в другом процессе. Часто ли это бывает? Почему нужно отвязывать диалог сохранения от процесса?

Дочитай тот пост до конца.

Если COM-сервер запускается в другом процессе.

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

Почему нужно отвязывать диалог сохранения от процесса?

Потому что нужно выжигать калёным железом интерфейсы между компонентами. Чем более гетерогенна система - тем более она адаптивна к изменениям. Все линуксовые десктопные мучения последних 15 лет - результат отсутствия публичных интерфейсов. Ни одна команда разработчиков не задекларировала что-то вроде «вот наш замечательный публичный интерфейс для взаимодействия с нашим творчеством, а теперь мы будем его реализовывать.»

Что толку с исходинков утилиты, завязанной на HAL или DeviceKit, если их авторы уже давным-давно сидят за макбуками?

Дело сдвинулось с мёртвой точки, только когда редахт породоил фридесктоп.орг и д-бас. Благодоря д-басу (который, собственно, выступает аналогом вендового com) стопитсот опенсорс-разработчиков смогли, наконец, родить совместимую работу в «системном трее».

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

Не вижу я особой разницы между запуском инсталлера на винде и на убунточке через вайн. Работает-то одинаково.

Как ты думаешь, что означают ЧИСЛА в именах библиотек?

Абсолютно ничего. Вместо чисел там могут быть хоть кириллические яти, главное те же самые яти передать в -Wl,-soname (man ld).

Технически это просто реализация позднего связывания - ничего больше.

Динамическая загрузка - тоже. Ты приведешь наконец качественные отличия COM от обычной lib*.so?

нужно выжигать калёным железом интерфейсы между компонентами.

Наверное, ты хотел сказать что-то другое.

Чем более гетерогенна система - тем более она адаптивна к изменениям.

Buzzword overload.

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

Это, может быть, и так, но к размышлениям о совместимости имеет косвенное отношение. COM - только стандарт доступа к компонентам. Если компоненты сломаются, никакой COM не поможет.

Тогда как МС спокойно заменяла одни запчасти на другие на протяжении добрых двадати лет.

Ага, ага. DDE, OLE, COM, всё срет в реестр и при шаге влево-вправо глючит и конфликтует. Не надо рассказывать про «спокойно». И, как я уже сказал, для совместимости со старым софтом одного COM мало.

man pkg-config

Потому что нет привязки к реализации на уровне двоичного образа процесса до момента использования.

А в *.so есть что ли? Вот так новости!

Ты уверен, что знаком с матчастью?

Благодоря д-басу (который, собственно, выступает аналогом вендового com) стопитсот опенсорс-разработчиков смогли, наконец, родить совместимую работу в «системном трее».

Два варианта: ты толсто троллишь или тупой. Реализация трея не пересылает ни единого байта через dbus. И ты не можешь об этом не знать. Или всё-таки можешь?

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

man pkg-config

А причем тут pkg-config? Я про то, что вместо циферок можно вписать что угодно, просто в самой динамиечской библиотеке прописывается ее «имя», с которым ld и связывает бинарник. ld открывает libmylib.so, видит, что имя библиотеки «libmylib.so.1» и пишет в результирующий бинарник, что он связан с библиотекой «libmylib.so.1». То, что пишут циферки вместо ятей — чистая условность и никакой версионности в эльфах отродясь не было и не предвидится.

То, что пишут циферки вместо ятей — чистая условность и никакой версионности в эльфах отродясь не было и не предвидится.

Да что ты говоришь.

сравним аудиторию маков с аудиторией линукса?

По-сравнению с виндой, аудитории мака и линукса равнозначно нитожны.

По-сравнению с виндой, аудитории мака и линукса равнозначно нитожны.

Всё же пути отступления нужны, на случай.

Ты приведешь наконец качественные отличия COM от обычной lib*.so?

Механизм конфигурации времени выполнения, управление временем жизни экземпляров ком-объектов, возможность прозрачной замены реализации без перезапуска всего приложения (но с перезапуском использования конкретноого ком-интерфейса). Интроспекция, наконец.

Наверное, ты хотел сказать что-то другое.

Если бы я хотел сказать что-то другое, я бы сказал что-то другое.

Buzzword overload.

Если ты не понимаешь смысла слов, так и скажи. Я ликбез проведу, мне не в пдалу.

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

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

Адаптивный - устойчивый к изменениям окружающей среды.

Пример на пальцах - появление новых устройств хранения данных (оптические диски, usb-флэшки, медиа-устройства), исчезновение старых (ленточные накопители).

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

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

Если компоненты сломаются, никакой COM не поможет.

Да. И что? Какое отношение имет стабильность софта к его переносимости и совместимости? Если проц сгорит, так и вообще ничего работать не будет.

DDE, OLE, COM, всё срет в реестр и при шаге влево-вправо глючит и конфликтует.

УМВР. ЧЯДНТ? ;)

Глючить, конечно, глючит. И конфликтовать тоже конфликтует. Но далеко не всё, и это лучше, чем не работает вообще. Так что хватит тезисов из серии «а у вас негров вешают».

для совместимости со старым софтом одного COM мало.

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

Твой поинт был в том, что исходный код автоматом дает совместимость.

Грустная же правда в том, что публичные интерфейсы при соборе дают большую совместимость и расширяемость, чем их (почти?) полное отсутствие при базаре.

По-сравнению с виндой, аудитории мака и линукса равнозначно нитожны.

Вылезай из криокамеры. У маков уже 30-40% рынка продаж последние года два.

не равнозначно
7% юзеров на системе, в которой нет зоопарка - сильно лучше чем 1.5% на разных дистрибутивах и de.

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

Это ремейк, чёрт побери, Rogue (который был развитием идей ещё более древней Adventure и, вообще, первенство Rogue весьма сомнительно т.к. в те годы вышли десятки независимых игр с одинаковым игропроцессом «dungeon crawl», типа Telengard, Ultima, Wizardry, Apple Manor), ремейком которого были Hack, Nethack, Dungeon Hack, Diablo и куча других подобных игр. Традиция была такая в геймдеве выпускать каждый год Rogue с обновлённой графикой, в то время как остальные студии пытались развить жанр. Суть игры всегда оставалась неизменной - есть огромное многоэтажное случайно генерируемое подземелье, наполненное монстрами, которые вываливают лут, скупаемый торговцами на поверхности и персонаж игрока, который выполнят роль посредника между монстрами и торговцами, попутно прокачивая уровни. Тогда же были написаны первые боты и была выдвинута идея, что рано или поздно рогалики станут настолько крутыми, что тупой ИИ обломает о них зубы. Про последние игры таких серий как Wizardry, Ultima, M&M, TES и не скажешь, что они выросли из примитивного геймплея Rogue. В то время как большинство (если не все) онлайновых MMORPG, типа Ragnarok, Lineage и сотен других корейских поделок не далеко ушли от обычных рогаликов.

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

Потому что нет привязки к реализации на уровне двоичного образа процесса до момента использования.

А в *.so есть что ли? Вот так новости!

Да, в случае с *.so мы имеем прибитое гвоздями имя библиотеки. Мы можем подменить библиотеку, можем изменить её имя, но не можем убрать саму привязку бинарника к имени библиотеки.

В случае с com/d-bus мы запрашиваем имя службы в общем реестре, и пользуемся полученным ответом. Кто дал этот ответ - нам фиолетово, у нас нет соответствия функция-имя бинарника Это позволяет какому-нибудь пиджину создавать иконку в трее, не выясняя, в каком же именно оконном менеджере он работает.

ем оно отличается от предыдущих версий?

отсутствием кнопки пуск, и одноцветным помойным контейнером, в качестве логотипа..

Разве это не очередная свиста с новым интерфейсом?

c новым, неудобным, унылым, убогим интерфейсом.
//fix

А то я человек темный, не ознакомлен с инновациями от M$.

Я Вам завидую...

Да, в случае с *.so мы имеем прибитое гвоздями имя библиотеки. Мы можем подменить библиотеку, можем изменить её имя, но не можем убрать саму привязку бинарника к имени библиотеки.

В случае COM мы имеем прибитое гвоздями имя интерфейса. Мы можем подменить реализацию, можем засунуть её в другой файл, но не можем убрать саму привязку бинарника к имени интерфейса. Загадка «найди отличие».

В случае с com/d-bus мы запрашиваем имя службы в общем реестре, и пользуемся полученным ответом. Кто дал этот ответ - нам фиолетово

В случае с *.so мы запрашиваем имя у линковщика. Что именно выдал линковщик — нам фиолетово.

Реализация трея не пересылает ни единого байта через dbus.

Окей, добаление флэшки в систему пересылает байт через д-бас?

Ты приведешь наконец качественные отличия COM от обычной lib*.so?

Механизм конфигурации времени выполнения, управление временем жизни экземпляров ком-объектов, возможность прозрачной замены реализации без перезапуска всего приложения (но с перезапуском использования конкретноого ком-интерфейса). Интроспекция, наконец.

Кроме интроспекции, всё это малозначащие технические детали. Правильный ответ: языковая нейтральность и интроспекция.

нужно выжигать калёным железом интерфейсы между компонентами.

Наверное, ты хотел сказать что-то другое.

Если бы я хотел сказать что-то другое, я бы сказал что-то другое.

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

Если компоненты сломаются, никакой COM не поможет.

Да. И что?

А то, что они сломаются. Так устроен опенсорс наших дней. Наличие COM-подобной технологии для него не было бы решающим.

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

CORBA запиливали - не взлетело. Насчет D-Bus - он никогда не предназначался на роль компонентной системы. Может быть кто-нибудь придумает реально удобный RPC, но это уж точно будет на D-Bus.

Твой поинт был в том, что исходный код автоматом дает совместимость.

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

Грустная же правда в том, что публичные интерфейсы при соборе дают большую совместимость и расширяемость, чем их (почти?) полное отсутствие при базаре.

Грустная (?) правда в том, что базар уделал собор по жизнеспособности.

Загадка «найди отличие».

А самому не судьба?

В случае COM мы ... не можем убрать саму привязку бинарника к имени интерфейса.

Еще как можем. Мы можем получить ответ, что нужного нам интерфейса в реестре не зарегистрированно, и реагировать на это. Расскажи, как ты будешь программно реагировать на отсутствие нужной библиотеки в системе?

Расскажи, как ты будешь программно реагировать на отсутствие нужной библиотеки в системе?

man dlopen

Кроме интроспекции, всё это малозначащие технические детали.

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

А то, что они сломаются. Так устроен опенсорс наших дней. Наличие COM-подобной технологии для него не было бы решающим.

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

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

Да, тут полностью согласен.

man dlopen

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

Кроме интроспекции, всё это малозначащие технические детали.

Нет, биндинг времени выполнения - многозначащая техническая деталь.

См. выше про динамическую линковку.

А то, что они сломаются. Так устроен опенсорс наших дней. Наличие COM-подобной технологии для него не было бы решающим.

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

В этих стандартах даже сегодня _настоятельной_ необходимости нет - общаться особо некому, а для остальных хватает C ABI.

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

В опенсорсе наших дней тупо нет сущности, выполняющей роль строителя платформы - с заботой о взаимодействии компонентов и обратной совместимости. Так что да, всё, что мы имеем, - это C compilation system родом из Unix-систем 70-80-х. Та diversity, которая позволила Linux выжить, скоро может стать причиной его застоя. Грустная ирония.

См. выше про динамическую линковку.

DLL Hell, да? ;) Зачем мешать в одну кучу разные пространства имен. Имена библиотек и имена доступных компонент - это ортогональные сущности.

В этих стандартах даже сегодня _настоятельной_ необходимости нет - общаться особо некому

Гномокеды аж по три - четыре версии самих себя выпустили от нехватки общения.

Та diversity, которая позволила Linux выжить, скоро может стать причиной его застоя. Грустная ирония.

Тоже согласен. Впрочем, те нишы, которые Linux занял сейчас - сервера для веба и платформы для эмбеддед, он и дальше будет успешно занимать.

Да что ты говоришь.

Теперь моя очередь спросить: ты вообще в курсе устройства ELF?

DLL Hell, да? ;)

Нет. DLL Hell возник потому, что Windows 1.x-3.x писали птушники, а команда NT не посчитала проблемы приложений достаточно важными.

Гномокеды аж по три - четыре версии самих себя выпустили от нехватки общения.

Да хоть четыреста. DE - вещь довольно замкнутая, для общения с ним хватит и D-Bus.

DE - вещь довольно замкнутая, для общения с ним хватит и D-Bus.

Если мы говорим о DE современного домашнего/офисного компа, то эта «замкнутость» должна включать в себя:

- целый список прилетающих в систему устройств - от принтеров/сканеров, до считывателей отпечатка пальца и 3д очков.

- сетевые соединения и конфигурации в любых видах с маршрутизацией от pptp до wifi

- произвольное появление/исчезновение устройств хранения любых видов SATA/firewire/media и т.д.

Горячую замену проца/памяти пока подождём. ;)

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