c-smile, Вы писалиАвтор: c-smile
Дата: 23.10.08
:
Как показывает практика даже просто делание билиотеки free создает гимор для разработчиков.
Чья практика показывает? Практика Linux? Или практика Qt, boost, OpenSSL или libxml2? Или практика FreeBSD, KDE или Gnome? Или может быть практика Android? И в чём собственно может заключаться гемор?
c-smile, Вы писалиАвтор: c-smile
Дата: 23.10.08
:
Скажем кого радует открытость кода Mozilla или WebKit? Есть здесь люди кто реально хоть раз туда лазил? Если да то а) зачем и б) что нашел?
Лично я туда не разу не лазил, но прекрасно представляю для чего туда люди лазают. Трудно представить более совершенную среду для установки собственных расширений, чем у Mozilla Firefox; и именно благодаря открытости исходных текстов и возможности досконального изучения принципов и механизмов работы Firefox, Thunderbird, etc. существует такое огромное количество расширений для них, в том числе очень нужных и эффективных.
ShaggyOwl, Вы писалиАвтор: ShaggyOwl
Дата: 22.10.08
:
Мне, как пользователю HTMLayout абстрактный опен-сорс в вакууме не интересен. Текущая ситуация с одним основателем, регулярным баг-фиксом и динамичным развитием, более чем подходит.
Каким образом открытость Qt или Boost мешает их регулярному баг-фиксу или динамичному развитию? Ответ: никаким!
Мне кажется, что вы немного путаете тёплое с мягким ...
Во-первых: Open-Source != педалить за бесплатно. На этом деле люди умеют зарабатывать кучу денег.
Во-вторых: Open-Source не всегда означает получить продукт бесплатно. Например Qt открыта, но небесплатна (по крайней мере, была до того, как её не купила Nokia и не расхалявила). Скажем в случае открытия исходников HTMLayout каким образом это сказывается на
technical support и
Buy HTMLayout Support now? ИМХО: никаким.
В-третьих: Open-Source != мусорка исходных текстов. Open Source, как правило, открывает исходники для чтения для всех, и для записи для тех кто в состоянии внести свою лепту в развитие продукта. Прекрасный пример тому: boost.
Всегда в лицензионом соглашении можно прописать, что для бесплатного использования библиотеки вы обязаны собирать данную библиотеку динамически и поставлять её вместе со своим продуктом + указать ссылку об использовании такой библиотеки в about/help местах продукта. К примеру так поступает сейчас Qt!
c-smile, Вы писалиАвтор: c-smile
Дата: 09.01.08
:
Вот такие вот размеры получились:
Full htmlayout: Not compreesed: 1,470,464 bytes, UPX compressed: 602,624 bytes
htmlayout, no <richtext>: Not compreesed: 1,212,416 bytes, UPX compressed: 504,832 bytes
htmlayout, no <richtext>, no AGG and so no SVG. essential version(*): Not compreesed: 1,085,440 bytes, UPX compressed: 455,168 bytes
htmlayout, --"-- and no JPG and PNG libs (loading through Imaging API so requires COM initialization), minimal version(*): Not compreesed: 999,424 bytes, UPX compressed: 397,312 bytes
На примере библиотеки Qt мы можем наблюдать разбиение продукта на логические модули по мере его развития. Т.е. если Qt версий 3.Х.Х собиралась в одну единственную dll, то начиная с версии 4, библиотека разбита на несколько модулей. Теперь, если я разрабатываю продукт с помощью Qt я тащу реально только те модули, которые мне действительно нужно, не прихватывая например неиспользуемые возможности QtAssistantClient4.dll, QtDesigner4.dll, QtNetwork4.dll, QtOpenGL4.dll, QtScript4.dll, QtSql4.dll, QtSvg4.dll, а беру только QtCore4.dll, QtGui4.dll и QtXml4.dll. Мне кажется, что подобное можно проделать и с HTMLayout, и если я, к примеру, не использую AGG, SVG и Richtext, то не тяну соответственно HTMLayoutAgg.dll, HTMLayoutSvg.dll и HTMLayoutRtf.dll, а беру только лишь HTMLayoutCore.dll и HTMLayoutGui.dll.
Что лично мне нравится при использовании библиотек с открытым исходным кодом, так это возможность собственно-ручно собрать эти библиотеки. При этом я:
Могу сам указать с какой CRT и каким образом линковаться. Будет ли эта CRT лежать в msvcrt.dll, в msvcr70.dll, в msvcr80.dll или в msvcr90.dll, или CRT вообще будет находиться в моём модуле, т.к. я слинкую его с CRT статически. Я вот даже не знаю, использует ли HtmLayout.dll С-Runtime, в зависимостях файла нет ссылки на msvcrt.dll, есть только ссылка на kernel32.dll, при этом судя по таблице импорта из kernel32 не импортируются CRT-шные функции, соответственно HtmLayout либо вообще не использует CRT либо линкуется с ней статически. При этом если верно второе, то при собственноручной сборке, я бы ни в коем случае не линковал бы HtmLayout.dll с CRT статически, а слинковал бы её с той же самой CRT динамически, что использую в своём проекте, а именно: msvcr90.dll + манифест бы ей встроил верный.
Могу сам убрать неиспользуемые мной фичи из целевой dll-ки. Часто библиотеки предоставляют такой механизм. Наример boost можно собирать с опциями
--without-math, --without-graph и --without-python, чтобы не компиллить неиспользуемые мной библиотеки. Или Qt можно собрирать с опциями -no-libjpeg, -no-libtiff, -no-libmng, -no-gif и так далее чтобы удалить некоторую функциональность из целевой dll-ки, либо собирать с опциями -system-libjpeg, -system-libtiff, -system-libmng, -system-gif чтобы такую функциональность сохранить, но реализована она будет через системные dll винды, что опять же уменьшит размер целевой dll-ки. Ведь как удобно было бы самому собрать HtmLayout.dll, при этом при сборке указать ключи наподобие: -no-agg, -no-svg и -no-richtext и при этом получить более чем на треть меньший размер HtmLayout.dll. Не правда ли?
Сам решаю упаковывать мне целевую dll с помощью UPX или нет. Лично меня нисколько не смущает размер целевого модуля (который и так будет запакован по самое нихочу в инсталляционном пакете с помощью Solid LZMA), зато смущает то, что упакованная dll-ка будет требовать больше памяти, будет грузиться дольше во время загрузки приложение всилу распаковки модуля, а также такая dll-ка потерят своё свойство разделяемости ибо при сбросе страниц оперативы позже будет подгружаться из файла подкачки, а не из своего родного модуля. Хотя, пардон, я конечно же могу распаковать dll-ку обратно, получив 1,8MB (1925120 bytes) вместо заявленных на сайте 600KB: "Small distribution size: HtmLayout.dll is about 600KB".
Здравствуйте, c-smile, Вы писали:
CS>Код местами нетривиальный и сильно специфический. В том смысле что сильно помочь в понимании
CS>того что происходит в том или ином случае наличие исходников врядли поможет.
Вот лично мне и не нужно понимать что происходит в недрах HTMLayout.dll, я не собираюсь править/отлаживать исходные коды, мне и смотреть на них не за чем ибо нет практического интереса: как правило, чтобы хорошо разбираться в таких достаточно больших по объёму проектах как HTMLayout, необходимо пройти некую обязательную "фазу накопления знаний", на которую у меня совершенно нет времени, следовательно я даже не пойму ничерта в сорцах HTMLayout. Мне лишь необходимо собрать HTMLayout.dll таким образом как я хочу и слинковать её как я хочу. И в конце концов я соберу именно DLL, слинкуюсь с HTMLayout динамически и честно поставлю её вместе с продуктом. Однако всилу закрытости исходников HTMLayout я лишён подобных удобств. :(
"Дайте мне возможность выпускать и контролировать деньги в государстве и – мне нет дела до того, кто пишет его законы." (c) Мейер Ансельм Ротшильд , банкир.
Здравствуйте, Rakafon, Вы писали:
R>Могу сам указать с какой CRT и каким образом линковаться. Будет ли эта CRT лежать в msvcrt.dll, в msvcr70.dll, в msvcr80.dll или в msvcr90.dll, или CRT вообще будет находиться в моём модуле, т.к. я слинкую его с CRT статически. Я вот даже не знаю, использует ли HtmLayout.dll С-Runtime, в зависимостях файла нет ссылки на msvcrt.dll, есть только ссылка на kernel32.dll, при этом судя по таблице импорта из kernel32 не импортируются CRT-шные функции, соответственно HtmLayout либо вообще не использует CRT либо линкуется с ней статически. При этом если верно второе, то при собственноручной сборке, я бы ни в коем случае не линковал бы HtmLayout.dll с CRT статически, а слинковал бы её с той же самой CRT динамически, что использую в своём проекте, а именно: msvcr90.dll + манифест бы ей встроил верный.
Это можно решить системой автоматических билдов разных вариантов DLL. У c-smile сейчас этого нет, но мы добавим
R>Ведь как удобно было бы самому собрать HtmLayout.dll, при этом при сборке указать ключи наподобие: -no-agg, -no-svg и -no-richtext и при этом получить более чем на треть меньший размер HtmLayout.dll. Не правда ли?
Большого выигрыша тут не получить, поэтому и заморачиваться особо не стоит.
R>Сам решаю упаковывать мне целевую dll с помощью UPX или нет.
Ну так распакуй. А потом перепакуй каким-нибудь 7zip'ом в инсталляторе.
R>Вот лично мне и не нужно понимать что происходит в недрах HTMLayout.dll, я не собираюсь править/отлаживать исходные коды, мне и смотреть на них не за чем ибо нет практического интереса: как правило, чтобы хорошо разбираться в таких достаточно больших по объёму проектах как HTMLayout, необходимо пройти некую обязательную "фазу накопления знаний", на которую у меня совершенно нет времени, следовательно я даже не пойму ничерта в сорцах HTMLayout. Мне лишь необходимо собрать HTMLayout.dll таким образом как я хочу и слинковать её как я хочу. И в конце концов я соберу именно DLL, слинкуюсь с HTMLayout динамически и честно поставлю её вместе с продуктом. Однако всилу закрытости исходников HTMLayout я лишён подобных удобств. 
Именно это можно скоро будет достаточно просто сделать.
Здравствуйте, Cyberax, Вы писали:
C>Большого выигрыша тут не получить, поэтому и заморачиваться особо не стоит.
Судя по сообщению от c-smile (
К вопросу о размерахАвтор: c-smile
Дата: 09.01.08
), то разница между Full Version и Minimal Version составляет 1,470,464 bytes — 999,424 bytes = 471,040 bytes, а это как никак (471,040/1,470,464=0.32) минус треть от размера полной версии. Так что думаю в особых случаях можно и заморочиться.
C>Ну так распакуй. А потом перепакуй каким-нибудь 7zip'ом в инсталляторе.
Ну так я и написал:
... Лично меня нисколько не смущает размер целевого модуля, который и так будет запакован по самое нихочу в инсталляционном пакете с помощью Solid LZMA
... Хотя, пардон, я конечно же могу распаковать dll-ку обратно, получив 1,8MB (1925120 bytes) вместо заявленных на сайте 600KB: "Small distribution size: HtmLayout.dll is about 600KB"
Просто мне кажется не совсем честным пункт на главной странице официального сайта "
5. Small distribution size: HtmLayout.dll is about 600KB uncompressed.", в то время как в скачанном SDK HTMLayout.dll весит более 700КБ, будучи при этом запакованной UPX-ом!
C>Именно это можно скоро будет достаточно просто сделать.
C>Это можно решить системой автоматических билдов разных вариантов DLL. У c-smile сейчас этого нет, но мы добавим :)
Т.е. я так понимаю вы запустите Cruise Control, который будет собирать разные версии HtmLayout.dll, в том числе слинкованную с различными CRT динамически/статически? VC++6, VC++7 (VS.Net-2003), VC++8 (VS.Net-2005), VC++9 (VS.Net-2008) и VC++10, которая скоро выйдет с поддержкой существующего пока только в draft'ах нового стандарта С++. При этом если слинковать со всеми этими CRT статически и динамически, то получится 10 вариантов DLL. Плюс платформы 32bit и 64bit => 20 штук. А Borland C++ Builder, MinGW, etc.? И вся эта dll-ная кодла будет лежать пожатой UPX-ом в SDK? Зачем весь этот гемор ради следования религиозным догмам типа "ни за что не откроем сорцы даже в режиме read-only". Или вы боитесь, что при их открытии их кто-то банально свистнет, нарушив все права собственности и не будет при этои подобающим образом наказан? Не пойму что такого плохого в том, что пользователи HtmLayout будут иметь возможность собирать HtmLayout.dll на целевой девелоперской тачке с использованием своих инструментов разработки со своей уникальной environment, также, как они это делают в случае использования Boost, Qt, OpenSSL, LibXml2, ZLib, etc.?
"Дайте мне возможность выпускать и контролировать деньги в государстве и – мне нет дела до того, кто пишет его законы." (c) Мейер Ансельм Ротшильд , банкир.
Здравствуйте, Rakafon, Вы писали:
C>>Большого выигрыша тут не получить, поэтому и заморачиваться особо не стоит.
R>Судя по сообщению от c-smile (К вопросу о размерахАвтор: c-smile
Дата: 09.01.08
), то разница между Full Version и Minimal Version составляет 1,470,464 bytes — 999,424 bytes = 471,040 bytes, а это как никак (471,040/1,470,464=0.32) минус треть от размера полной версии. Так что думаю в особых случаях можно и заморочиться.
100Кб в запакованном виде.
R>... Хотя, пардон, я конечно же могу распаковать dll-ку обратно, получив 1,8MB (1925120 bytes) вместо заявленных на сайте 600KB: "Small distribution size: HtmLayout.dll is about 600KB"[/q]Просто мне кажется не совсем честным пункт на главной странице официального сайта "5. Small distribution size: HtmLayout.dll is about 600KB uncompressed.", в то время как в скачанном SDK HTMLayout.dll весит более 700КБ, будучи при этом запакованной UPX-ом!
Ну а что тебе не нравится-то, я не понимаю?
R>Т.е. я так понимаю вы запустите Cruise Control, который будет собирать разные версии HtmLayout.dll, в том числе слинкованную с различными CRT динамически/статически? VC++6, VC++7 (VS.Net-2003), VC++8 (VS.Net-2005), VC++9 (VS.Net-2008) и VC++10, которая скоро выйдет с поддержкой существующего пока только в draft'ах нового стандарта С++. При этом если слинковать со всеми этими CRT статически и динамически, то получится 10 вариантов DLL. Плюс платформы 32bit и 64bit => 20 штук.
Угу. Только всё ещё хуже будет, когда добавятся Linux и Mac OS X
R>А Borland C++ Builder, MinGW, etc.? И вся эта dll-ная кодла будет лежать пожатой UPX-ом в SDK?
BCB вообще никому не нужен. MinGW будет.
R>Зачем весь этот гемор ради следования религиозным догмам типа "ни за что не откроем сорцы даже в режиме read-only". Или вы боитесь, что при их открытии их кто-то банально свистнет, нарушив все права собственности и не будет при этои подобающим образом наказан?
Это вопросы к c-smile. Он за лицензирование исходников получает деньги, которые идут на поддержку библиотеки. Эта одна причина сама по себе может быть важнее всех твоих доводов.
R>Не пойму что такого плохого в том, что пользователи HtmLayout будут иметь возможность собирать HtmLayout.dll на целевой девелоперской тачке с использованием своих инструментов разработки со своей уникальной environment, также, как они это делают в случае использования Boost, Qt, OpenSSL, LibXml2, ZLib, etc.?
См. выше.
Тем более, что распространение в бинарной форме в виде кучи DLL-ок не так уж и необычно. Скажем, так многие коммерческие 3D-движки распространяются.
Здравствуйте, Rakafon, Вы писали:
C>>Большого выигрыша тут не получить, поэтому и заморачиваться особо не стоит.
R>Так что думаю в особых случаях можно и заморочиться.
Изложи свои особые случаи.
C>>Ну так распакуй. А потом перепакуй каким-нибудь 7zip'ом в инсталляторе.
R>Ну так я и написал:... Лично меня нисколько не смущает размер целевого модуля, который и так будет запакован по самое нихочу в инсталляционном пакете с помощью Solid LZMA
R>... Хотя, пардон, я конечно же могу распаковать dll-ку обратно, получив 1,8MB (1925120 bytes) вместо заявленных на сайте 600KB: "Small distribution size: HtmLayout.dll is about 600KB"
Просто мне кажется не совсем честным пункт на главной странице официального сайта "5. Small distribution size: HtmLayout.dll is about 600KB uncompressed.", в то время как в скачанном SDK HTMLayout.dll весит более 700КБ, будучи при этом запакованной UPX-ом!
Эта цифра, да, устарела. Поправлю.
Когда-то было 600kb, даже 452kb (версия 1.0.2.10 отсюда
http://www.codeproject.com/KB/wtl/HtmLayout.aspx)
Много воды утекло. Пришлось добавлять PNG.lib (за для поддержки animated PNG) и JPEG.lib.
Потом добавилась AGG, потом пришлось втсраивать полную UNICODE table c PGBA (
http://crl.nmsu.edu/~mleisher/ucdata.html)
Выкинуть что-то можно конечно. Но стоит ли та овчинка выделки.
C>>Именно это можно скоро будет достаточно просто сделать.
C>>Это можно решить системой автоматических билдов разных вариантов DLL. У c-smile сейчас этого нет, но мы добавим
R>Т.е. я так понимаю вы запустите Cruise Control, который будет собирать разные версии HtmLayout.dll, в том числе слинкованную с различными CRT динамически/статически? VC++6, VC++7 (VS.Net-2003), VC++8 (VS.Net-2005), VC++9 (VS.Net-2008) и VC++10, которая скоро выйдет с поддержкой существующего пока только в draft'ах нового стандарта С++. При этом если слинковать со всеми этими CRT статически и динамически, то получится 10 вариантов DLL. Плюс платформы 32bit и 64bit => 20 штук. А Borland C++ Builder, MinGW, etc.? И вся эта dll-ная кодла будет лежать пожатой UPX-ом в SDK? Зачем весь этот гемор ради следования религиозным догмам типа "ни за что не откроем сорцы даже в режиме read-only". Или вы боитесь, что при их открытии их кто-то банально свистнет, нарушив все права собственности и не будет при этои подобающим образом наказан? Не пойму что такого плохого в том, что пользователи HtmLayout будут иметь возможность собирать HtmLayout.dll на целевой девелоперской тачке с использованием своих инструментов разработки со своей уникальной environment, также, как они это делают в случае использования Boost, Qt, OpenSSL, LibXml2, ZLib, etc.?
Открытие исходников стоит денег. Например разработка комплекса лицензий аналогичных Мозилловской MPL стоит в пределах 20тыс USD.
Короче, мне проще открыть их скажем десятку людей а не гадать кто исхитрился скомпилировать очередной
"I have a program called antivirus 2010 that has invaded my computer and the file says it originated at your company. Do you know anything about this program and how I can remove it from my computor."
А так у меня хоть есть шанс вычислить того злыдня.
