Все новости от 26 мая 2006 г.

Microsoft: OpenDocument слишком медленный

«OpenDocument замедляет работу с документами до такой степени, что его нельзя считать удовлетворительным, — сказал ZDNet UK генеральный менеджер Microsoft по стратегии продуктов для информационных работников Алан Йейтс. — Между тем формат Open XML оптимизирован по быстродействию. XML значительно медленнее двоичных форматов, и мы сделали так, чтобы пользователи не замечали большой разницы в производительности».

Йейтс сослался на исследование, выполненное ZDNet.com, в котором OpenOffice.org 2.0 сравнивается с XML-форматами, используемыми в Microsoft Office 2003. Однако управляющий директор ODF Alliance Марино Марчич считает это сравнение неправомерным, так как собственно Open XML не тестировался, и проверялась всего одна реализация OpenDocument Format (ODF).

«Продуктов Open XML еще просто не существует, так что сравнивать не с чем, — сказал он. — А ODF поддерживают и используют не только OpenOffice, но и множество других приложений, включая StarOffice, IBM Workplace, KOffice, Abiword/Gnumeric и Google Writely. Все они демонстрируют разную производительность». Он добавил, что изначально OpenOffice.org не был оптимизирован для ODF, но со временем будет.

Марчич утверждает, что компаниям будет труднее освоить Open XML, так как документация по нему содержит свыше 4000 страниц, тогда как в документации по ODF их всего 700. «Скептики скажут, что документации так много, что только одно приложение сможет поддерживать этот формат как следует. Мне после первого прочтения документации (по Open XML) показалось, что Microsoft пытается изобрести колесо, тогда как ODF свободно ссылается на существующие стандарты, такие как SVG (Scalable Vector Graphics)».

Но Йейтс утверждает, что большой объем документации Open XML объясняется тем, что она охватывает больше функций. «Эта документация значительно глубже документации по OpenDocument Format — в ней описывается гораздо больше функций, опций и примеров работы пользователя».

В начале этого месяца Международная организация по стандартизации утвердила ODF, после чего аналитическая фирма Gartner понизила прогнозируемую вероятность того, что ISO утвердит формат Microsoft Open XML.

Йейтс не согласен с анализом Gartner и говорит, что «места хватит для многих форматов документов». Он назвал анализ Gartner «чрезвычайно странным и вводящим в заблуждение». «Мы призываем аналитиков собрать больше данных и глубже разобраться в ситуации», — сказал он.

На прошлой неделе европейская организация по стандартизации ECMA International опубликовала промежуточный проект формата Open XML. Ожидается, что он будет утвержден ECMA к концу года, отметил Йейтс. 

 Предыдущие публикации:

 В продолжение темы:

Обсуждение и комментарии

	Угрюмый anonymous 26 May 2006 2:22 PM
"большой объем документации Open XML объясняется тем, что она охватывает больше функций" Если мне предложат прочитать 4000 страниц и по быстренькому наваять поддержку OpenXML то я застрелюсь наверно, или уволюсь, но аффтара этого формата полюбому на %%% пошлю.
	Геморрой 26 May 2006 2:29 PM
А что другого можно ждать от МС в отношении конкурента? Только обсера. Форматы от МС вообще практически не документированы официально (во всяком случае, простому смертному их не надыбать), дока по МС ХМЛ с их сайта тоже отнюдь не тощенькая. А разработчику МС АПИ предлагает, а не описание. И за это еще бабло отстегивать. Одной из причин отказа в стандартизации МСовских фич стала их закрытость и отказ в открытии.
	Tracker 26 May 2006 2:46 PM
Лажают парни. Если не умееш писать программы - ищи другую работу! Медленно :)))
	A 26 May 2006 2:56 PM
Медленный формат хранения данных - это что-то новенькое. Интересно, файлы TXT - это быстрые файлы или медленные ? :)
	eXOR 26 May 2006 3:33 PM
Видать Open XML имеет какие-то встроенные хаки для msxml парсера :).
	http://ru.wikipedia.org/wiki/Prius 26 May 2006 3:38 PM
> Медленный формат хранения данных - это что-то новенькое да старенькое ето, старенькое "забота" о потребителе называется
	Угрюмый anonymous 26 May 2006 5:32 PM
>> Интересно, файлы TXT - это быстрые файлы или медленные ? :) >"Что быстрее - OpenBSD или XML?" © LOR С микросовтом и не до такого маразма додуматься можно :D А ещё бывают быстрые аудио и видео форматы. Они быстрее плеерами играются. Наверняка новый WMP значительно быстрее чем JPEG на экране . JPEG с частотой 85Гц на экране показывается а WMP минимум с 250Гц!
	M&M's 26 May 2006 8:19 PM
Ржунимагу :-)) Кстати, Йейтс как-то подозрительно напоминает Гейтс... Это к слову...
	Банч 26 May 2006 10:29 PM
прежде чем прикалываться, посмотрите кто провёл исследования на скорость форматов ... небезизвестный Джордж Оу :)
	A 26 May 2006 10:52 PM
Тут уж без разницы, кто провел такое "исследование". Само понятие "скорость форматов" является полной бессмыслицей. Народ в полный рост исследует многострадального сферического коня в вакууме :)
	Skull - sibskullmail.ru 27 May 2006 9:49 AM
2 A: > Интересно, файлы TXT - это быстрые файлы или медленные ? :) Конечно, медленные! Они в OpenOffice.org медленно открываются :) Мда, у мсовцев весеннее обострение. То форматы у них медленные, то "документация значительно глубже документации по OpenDocument Format — в ней описывается гораздо больше функций, опций и примеров работы пользователя" - какие такие примеры работы пользователя при работе с форматом документа? Они что, предлагают вручную документы в их запутанном XML править? Оригиналы! Точнее нет, шизофреники. Живут в собственной вселенной. :)
	anonymous c LOR 27 May 2006 10:33 AM
менеджер Microsoft Алан Йейтс слишком медленный. В смысле тормоз. У формата не может быть скорости.
	Yuri 27 May 2006 3:44 PM
>У формата не может быть скорости. Да неужели? Ну, попробуй-ка тогда записывать все файлы в формате хексдампа, закодированного поверх еще какой-нибудь навороченной криптозащитой с ключем длиной в 100К - а потом поделищься впечатлениями, может быть у формата скорость или нет :-) Чего ерундой-то заниматься? Что хотел сказать этот менеджер - вполне понятно: файлы в их формате обрабатываются быстрее. А уж насколько это правда, вопрос другой.
	Yuri 27 May 2006 3:54 PM
2Геморрой: > Форматы от МС вообще практически не документированы официально > (во всяком случае, простому смертному их не надыбать), дока по > МС ХМЛ с их сайта тоже отнюдь не тощенькая. А разработчику МС > АПИ предлагает, а не описание. И за это еще бабло отстегивать. > Одной из причин отказа в стандартизации МСовских фич стала их > закрытость и отказ в открытии. Как было сказано весьма давно, "невежество - не аргумент". Форматы файлов МС Оффиса были уже хрен знает сколько лет назад опубликованы в MSDN, и доступны и на сайте Майкрософта, и в виде выдранных и скомпилированных копий по всему Интернету. И когда наша контора писала фильтры для конвертации кучи типов файлов из одного формата в другие, то как раз с майкрософтовскими форматами никаких осбых проблем не возникло. Вот со всякими там QUark Express или Adobe Indesign - там да, действительно как ты и написал: описаний форматов не было, а было только АПИ для доступа, да и то пригодное только для написания плагинов к купленным у этих фирм редакторам (а написать отдельный конвертер с помощью этих АПИ было невозможно).
	http://ru.wikipedia.org/wiki/Prius 27 May 2006 4:34 PM
> Чего ерундой-то заниматься? Что хотел сказать этот менеджер - вполне понятно: платить, за "быстрый" формат выгодно для потребителя, обалдевшего фактами
	Геморрой 27 May 2006 5:10 PM
2(Yuri) Иногда и невежество - аргумент. Опубликованное МСом без фич. И с кчей недокументированных возможностей. А лазить по территории инета влом. Кстати, а чем эта позиция лучше абсолютно такой же позиции линуксоидов: "в нете все есть". Старый формат опубликован как Compound, без подробностей. В новом тоже не все присутствует. Чтобы не препираться долго, один из аргументов ИСО - нет полного описания. Охотно могу представить, что лично я прохлопал какую-то ссылку в МСДН. Но когда такое заявляет ИСО, для меня аргумент, повесомее юриев.
	M&M's 27 May 2006 8:35 PM
2 Геморрой: > Иногда и невежество - аргумент Иногда и 3.14здюля - аргумент... Даже чаще, чем невежество
	linuxsuxx.narod.ru - lssuxx.com 27 May 2006 9:51 PM
МАКРАСАЙТ РУЛИТ!!! ТКО НЕ СЛОГЛАСЕН САСЕТ
	linuxsuxx.narod.ru - lssuxx.com 27 May 2006 9:53 PM
Microsoft РУЛЕЗ, ВСЁ АСТАЛЬНОЕ КАЛ И НАДО ЕВО ИСТРИБЛЯТЬ
	anonymous c LOR 28 May 2006 7:43 AM
2 Yuri: скорость записи, это и есть скорость записи. точка. > Что хотел сказать этот менеджер - вполне понятно он хотел сказать "покупайте наших слонов", а сказал "софтина, которую мне дали медленно работоет". Нито ни другое прямого отношения к OpenDoc не имеет.
	http://labs.google.com/ 28 May 2006 2:57 PM
хотя бы и медленнее работают сегодняшние редакторы с ОпенДок-ом (во что верится с трудом) ето что, причина игнорировать стандарт ISO ? например, русский язык хуже английского (тут я с Тургеневым не согласен;) ето что, причина русский язык не поддерживать ?! совсем охерел Уильям Гейтц, школьник-.ять-недоучка, всю планету в ослов превращает своими (чужими) вонючими деньгAми пора бы ж Андерсен-девочке указать на голый гейтцевский зад (извините, навеяло ... легким слогом нашего предыдущего товарища;)
	Ender 29 May 2006 8:30 AM
2A: "Формат не может быть быстрым или медленным. Скорость работы с форматом определяется конкретной программно-аппаратой реализацией." Все очень просто. Любой программе нужно составить какое-то внутреннее представление документа на основе прочитанных данных и метаданных. Вопрос состоит в том сколько действий придется программе проделать от физического чтения файла документа, до получения этого представления. Так что есть у формата "скорость".
	Угрюмый anonymous 29 May 2006 8:50 AM
2 Ender >Так что есть у формата "скорость". Ты ещё скажи, что программа писаная на асме в 100 раз быстрее работает, чем таже но на Жабе. Это повод писать на асме? А у мекросовта всё так работает, быстро, хорошо, но почемуто всё время через жопу. (в очередной раз смотрю, как VS2005 вместе с SQL SMS2005 на гиг в своп садятся)
	Skull - sibskullmail.ru 29 May 2006 10:19 AM
2 Ender: > Так что есть у формата "скорость". Конечно. Только в случае XML vs. бинарный формат. Но MS же предлагает свой XML-ный формат. А разница между парсингом двух форматов на XML практически никакой (если XML не содержит бинарных вставок). Поэтому и хочется сказать MS: "чья бы корова мычала". :)
	Shamlo 29 May 2006 10:40 AM
А у меня есть претензии к Майкрософт. Их SQL Server слишком медленный. Гораздо медленнее MySQL. Да и сами Винды могли бы быть побыстрее.
	straus 29 May 2006 10:44 AM
2Shamlo теперь, держитесь, скорее всего это конец...
	Wintermute - devnul.ru 29 May 2006 11:12 AM
А у меня есть претензии к Shamlo. Слишком много гонит. Гораздо больше, чем все остальные. И примеры мог бы подбирать пореалистичнее.
	Wintermute - devnul.ru 29 May 2006 11:16 AM
2 Skull: "разница между парсингом двух форматов на XML практически никакой (если XML не содержит бинарных вставок)" Скажи, ты действительно веришь в вышесказанное? Ведь любой, кто работал с XML-парсерами (что SAX, что DOM), знает, что разница между парсингом 2 представлений одних и тех же данных в XML может быть огромна. Тупой пример - в одном представлении теги однобуквенные, в глобальном пространстве имен, и парсер об этом знает, в другом - "нормальные" длинные имена и пространства имен. Какой формат будет быстрее парситься?
	Геморрой 29 May 2006 11:33 AM
M&M's-у. А отдача не замучает при Вашей аргументации? . МС позиционировала свой продукт со слоганом "каждая домохозяйка может". И это прилипло насмерть. Переход с Вин98 на ВинХП вызвал у юзеров шок, автопрячущиеся меню в Офисе2000 до сих пор вызывают ступор. Начальство по-прежнему долбит "надо было вчера". Посему лазить по МСДН могут не все. "Количество разума на Земле постоянно, а население растет" (с) не мое. . Уверен, что скорость парсинга МС ХМЛ будет на уровне. Под виндой. А ОпенДок потормознее, но везде одинаково. В любом раскладе отсутствие поддержки стандарта плохо. Хотя бы с маркетинговой точки зрения.
	злой 29 May 2006 11:36 AM
2Wintermute я не видел ни одного из этих двух форматов, но уверен, что в них нормальные длинные имена и парсятся в реализации они SAX'ом. И поэтому, сказать, что наш XML быстрее их, это тупизм и бред. Даже если, например, в Open XML абзац описывается 5-ю вложеннными элементами, а у MS одним, то разница будет микроскопическая при разборе. Довод, что их формат куруче, из-за того, что у них докуметация в 6-ть раз меньше, так это вообще перл :))) макрузоиды жгут.
	Andrew - luan2002mail.ru 29 May 2006 12:08 PM
Я давно не использую MS Office на работе, дома. Open Office - красавчик, недорогой. Открытый формат позволяет легко манипулировать программными средствами документы, созданные в OpenOffice. Эти возможности на порядок превышают, возможности MS Office. Плюс без каких либо ограничений присущих MS : нужен windows server, MS Office на сервере ????, MS Office на клиентах, ActiveX (наконец-то он погибает :) )
	Хад 29 May 2006 12:17 PM
В мелкософте - одна проектная группа была нормальной, та, которая создала Win32. До сих пор на этом держатся.
	нц 29 May 2006 12:30 PM
2 Andrew: не позволяет, а позволит.. когда-нибудь. даже несмотря на стандарт и полное описание - всеравно будет жопа с обработкай в разных приложениях
	Shamlo 29 May 2006 12:42 PM
> straus: теперь, держитесь, скорее всего это конец... Конец чего? Конец Света? :) > Wintermute: А у меня есть претензии к Shamlo. Слишком много > гонит. Гораздо больше, чем все остальные. Претензии не принимаются! а) Он гонит вполне умеренно. б) Гораздо меньше, чем все остальные. > И примеры мог бы подбирать пореалистичнее. Например?
	Andrew 29 May 2006 12:47 PM
Почему позволит ? Есть стандарт, есть программная библиотека, которая раскладывает xml файлы, по классам / объектам. С помомошью этот библиотеки производится трансформация документа. На выходе документ, проще всего стандарт, которого описан, а не в форматие по ходу движения, которому добавили со злым умыслом не нужные и не поддерживаемые до селе фичи.
	Bilbo - chelyabinfromru.com 29 May 2006 12:47 PM
Что на мой взгляд может влиять на скорость работы с XML: 1) количество тегов (каждый тэг - это вызов функции при парсинге); 2) наличие микропарсинга (как в плюс так и в минус); 3) поддержка CSS; 4) использование идентификаторов и путей XPath (я уже и не говорю об XLink/XPointer). Так что форматы могут сильно отличаться по скорости. Плюс качество работы с форматом (реализация).
	Хад 29 May 2006 1:01 PM
Самое инетересное, что скорее всего : 1. 80% документов в мире < 200 Kbyte Тест в OpenOffice (прямо по ходу написания) - открытие / сохранение намного меньше 2 с. 2. 18% документов в мире > 200 Kbyte < 1 Mbyte Тест в OpenOffice (прямо по ходу написания) - открытие / сохранение всё равно меньше 2 с. 3. 2% документов в мире > 1 Mbyte Тест в OpenOffice (прямо по ходу написания) - открытие / сохранение > 2 c <<<< минут И с такими параметрами, мне честно говоря, наплевать как шустро' работает с документами MS Office. C реализацией MS всегда была на высоте :)
	Shamlo 29 May 2006 2:12 PM
> Bilbo: Так что форматы могут сильно отличаться по скорости. Безусловно, это все правильно. Но это - НЕ СКОРОСТЬ! Скорость -это величина, которая характеризует менее абстрактные вещи. Чтобы можно было говорить о скорости, нужно иметь КОНКРЕТНУЮ реализацию и НЕ МЕНЕЕ КОНКРЕТНУЮ аппаратную конфигурацию. Если же речь идет просто о формате как таковом, то описанный параметр можно было бы назвать "коэфициентом оверхеда". Вполне возможно, что этот коэфициент оверхеда для ODF больше, чем он же для Open XML. Ну и что? У Хаммера, например, КПД намного ниже, чем у Оки, но владельцам первых это не мешает. Там и бензобак специально сделан побольше, и вообще есть еще много иных достоинств. Тоже самое и с форматами. Если бы они сказали, что у формата высокий коэфициент оверхеда, то никто бы ни разу не испугался. Коэфициент он на то и коэфициент, чтобы его увеличение можно было чем-то скомпенсировать. Поэтому они специально говорят про скорость. Словосочетание "низкая скорость" похоже на окончательный приговор и звучит намного более драматично, чем "высокий оверхед".
	A 29 May 2006 2:16 PM
2 Ender: > Так что есть у формата "скорость". Хорошо. Какой формат числовых данных "быстрее" - бинарный или текстовый ?
	Wintermute - devnul.ru 29 May 2006 2:22 PM
2 злой: "я не видел ни одного из этих двух форматов, но уверен, что в них нормальные длинные имена и парсятся в реализации они SAX'ом" Это был всего-лишь пример, как можно сделать разбор быстрее. Уже одно исключение пространств имен ускоряет разбор заметно, раза в 1.5. Пробовал expat, MS XML и .Net. "Даже если, например, в Open XML абзац описывается 5-ю вложеннными элементами, а у MS одним, то разница будет микроскопическая при разборе" Попробуй, убедись. Чем больше вложенность элемента, тем дольше рабор. Разумеется, я речь веду о реальных файлах в сотни килобайт и мегабайты, а не об игрушках в пару кил.
	Wintermute - devnul.ru 29 May 2006 2:31 PM
2 A: "Какой формат числовых данных "быстрее" - бинарный или текстовый?" Некорректный вопрос, на который есть корректный ответ. Бинарный. С любой точки зрения. Память - числа в двоичном представлении "в среднем" меньше места занимают (исключения - целые числа малой разрядности при любом основании). Чтение/запись - тоже быстрее, даже если не нужно производить преобразования в двоичную форму. Передача по сети - аналогично. Вычисления - реализуйте на досуге целочисленное деление чисел в текстовом формате без перевода в двоичный. Разумеется, у текстовых данных есть достоинства - человеку легко их читать и модифицировать, отсутствует проблемы разрядности, точности и порядка байт.
	Fhrb 29 May 2006 2:50 PM
Такого маразма я еще не читал. Похоже, в мелкософте начинаются предсмертные глюки :о) Быстрый формат - это тот, который будет открываться 0,1 с, а медленный - 0,2 с? А кто заметит разницу?
	Shamlo 29 May 2006 3:20 PM
> Wintermute: Некорректный вопрос, на который есть корректный > ответ. Бинарный. С любой точки зрения. А вот и не с любой! А только с точки зрения обработки данных в этом формате. Т.е. речь идет не про "скорость формата", а про "скорость обработки данных в формате". Происходит как бы незаметная подмена понятий. Если бы у формата была "скорость", то она была бы у него даже тогда, когда данные в этом формате никто не обрабатывает. По крайней мере, эта "скорость" никак не зависела бы от того, кто эти данные обрабатывает - машина или человек. Ведь это бы была скорость самого формата, а не скорость конкретного обработчика.
	Bilbo - chelyabinfromru.com 29 May 2006 3:25 PM
> Shamlo: "Если бы они сказали, что у формата высокий коэфициент оверхеда, то никто бы ни разу не испугался" Допустим. В таком случае можно ли сейчас или когда либо говорить о скорости форматов? Давайте оценивать "коэфициент оверхеда". Это ведь сделать можно. И именно это и может придать разговору необходимую конкретику. Аналогии - вещь мощная, но зыбкая.
	Bilbo - chelyabinfromru.com 29 May 2006 3:38 PM
Для меня фактом является то, что формат XML - это часть архитектуры софта. Компенсировать его ничем не нужно, а вот учитывать в нём особенности архитектуры можно и должно. К примеру, огромное влияние окажет ориентированность на конвейерную обработку или работу со структурами данных. Грубо можно провести параллель с SAX и DOM. Соответственно можно говорить о концепции формата. Какую цель ставят перед собой его разработчики, каковы границы его применения, какова парадигма его использования, какую степень свободы будут иметь разработчики реализации? В целом я не сомневаюсь, что у MS получится достойный формат, но вот насколько он окажется жизнеспособным за пределами реализации MSOffice - это вопрос. Соответственно вопрос, насколько он нам нужен в роли стандарта?
	Хад 29 May 2006 3:48 PM
Очень не нужен :)
	Shamlo 29 May 2006 4:13 PM
> Bilbo: Давайте оценивать "коэфициент оверхеда". Это ведь > сделать можно. Давайте. Но нельзя оценивать коэфициент в отрыве от того, с связке с чем он применяется. Т.е. для оценки влияния этого коэфициента на итоговую скорость необходимо задать аппаратную конфигурацию. Именно она является тем "рабочим телом", которое по-разному "затормаживают" форматы данных, имеющие тот или иной оверхед. Вот у меня, например, Pentium-D 3.0GHz + 2 гига памяти. Когда я открываю средний документ в ODF, я вообще не ощущаю никакой задержки. Она, наверное, есть, но до сих пор я ее не замечал. Соответственно, мне не очень понятна точка зрения, суть которой в том, что данный формат что-то там затормаживает. Рассуждения на эту тему вызывают у меня улыбку... если не усмешку. А как у вас? И вообще, пусть каждый задаст себе простой вопрос. Напрягает ли его задержка при открытии/сохранении документов в формате ODF?
	fi 29 May 2006 4:20 PM
>> 2 A: "Какой формат числовых данных "быстрее" - бинарный или текстовый?" >Некорректный вопрос, на который есть корректный ответ. Бинарный. С чего бы вдруг? Считывание с диска - операция блоковая - значит без разницы - если только число меньше 512 знаков. Передача по сети проще - не нужно преобразовывать в BE :), ну а скорость будеть определятся накладными расходами, а не разницей в несколько байт. И сегодняшняя конвееризация в процессоре привела скорость преобразования a2l к пересылке данных из памяти в регистер.
	M&M's 29 May 2006 4:39 PM
Сравнивать числовые форматы, так уж двоичный и щестнадцатиричный, например.
	A 29 May 2006 4:52 PM
2 Wintermute: > Некорректный вопрос Чем в плане корректности этот вопрос отличается от вопроса, на который ответила MS ? И то и другое сравнение некоей "скорости" форматов. > на который есть корректный ответ. Бинарный. С любой точки зрения. А вот и не верно. Про блочное чтение и передачу уже говорили. Про преобразование при передаче по сети тоже (например, для передачи между ppc и x86 преобразование обязательно из-за различий в принципе хранения чисел на уровне архитектуры железа). Еще не сказали про отображение. Посчитайте, сколько машинных операций нужно сделать, чтобы вывести на экран число, представленное в бинарном виде. Хотя бы для целых чисел. Вот и получается, что у формата нет собственной скорости, иначе бы она была постоянной для любой операции. Ели же скорость меняется в зависимости от операции, то это уже скорость обработки формата или скорость операции. Собственно, Shamlo об этом сказал.
	Wintermute - devnul.ru 29 May 2006 4:56 PM
2 Shamlo: "А вот и не с любой! А только с точки зрения обработки данных в этом формате" Shamlo, прочтите еще раз оригинальный вопрос: "Хорошо. Какой формат числовых данных "быстрее" - бинарный или текстовый ?" и закругляйтесь со словоблудием.
	Bilbo - chelyabinfromru.com 29 May 2006 5:04 PM
> Shamlo: Вот у меня, например, Pentium-D 3.0GHz + 2 гига памяти. Рад за Вас :) Но я надеюсь, что формат разрабатывается не только для PC, но и для мобильных устройств. Там разница "эффективности" форматов может быть заметна. И еще, судя по всему мы не совсем согласовали терминологию. Параметр скорости или "коэфициент оверхеда" - давайте считать один из них (мне без разницы) независимым от аппаратной конфигурации. Или считать, что проводится стресс-тестирование формата.
	Wintermute - devnul.ru 29 May 2006 5:07 PM
2 A: "А вот и не верно. Про блочное чтение и передачу уже говорили" Ну и сразу возникла оговорка: "если только число меньше 512 знаков". С ходу привожу тип BigInteger из Smalltalk, в котором число знаков легко может превысить 512. А если мы работаем с массивом чисел? Что проще - считать блок 8-байтных double или эквивалентный набор строк? "Про преобразование при передаче по сети тоже" Скажите, вы серьезно верите, что вызов htoi/itoh или их эквивалентов для чисел с плавающей запятой будет выполняться дольше, чем printf/scanf? "Еще не сказали про отображение. Посчитайте, сколько машинных операций нужно сделать, чтобы вывести на экран число, представленное в бинарном виде. Хотя бы для целых чисел." Так что там с делением текстовых строк? :) Алгоритм, скажем, обратной трассировки луча с представлением данных в виде текста не приведете? ;) "Вот и получается, что у формата нет собственной скорости" Мы говорим о точности формулировок или о том, с каким форматом операции производятся быстрее?
	Shamlo 29 May 2006 5:17 PM
> Bilbo: Но я надеюсь, что формат разрабатывается не только для > PC, но и для мобильных устройств. Там разница "эффективности" > форматов может быть заметна. Здесь согласен. Но мобильные устройства - это довольно отдельная вещь. Более разумно делать преобразование формата при переносе документов, чем отказываться от вкусных (но ресурсоемких) фич на десктопе ради скорости на мобильных устройствах. > И еще, судя по всему мы не совсем согласовали терминологию. > Параметр скорости или "коэфициент оверхеда" - давайте считать > один из них (мне без разницы) независимым от аппаратной > конфигурации. Мне видится такая формула: Скорость = К. оверхеда * Возможности аппаратуры. Т.е. коэфициент оверхеда не зависит от аппаратуры, но скорость зависит одинаково как от оверхеда так и от аппаратуры.
	Shamlo 29 May 2006 5:29 PM
> Wintermute: Мы говорим о точности формулировок или о том, с > каким форматом операции производятся быстрее? Здесь важно определить какие мы имеем ввиду операции. Если операции открытия документа... то как вам такой аргумент? Операция открытия документа в майкрософтовском XML-формате в OpenOffice.org вообще не производится, т.е. ее скорость равна нулю. Понятно, что можно слегка ускориться, купив майкрософтовский Office. Но чуть большая скорость за ТАКИЕ деньги что-то не очень мотивирует.
	A 29 May 2006 5:55 PM
2 Wintermute: > Скажите, вы серьезно верите, что вызов htoi/itoh или их эквивалентов для чисел с > плавающей запятой будет выполняться дольше, чем printf/scanf? Опять таки, это зависит не от формата, а от реализации алгоритма операций. Возьмем, к примеру, реализацию htoi в виде непосредсвенно кода в программе. Получили выигрыш как минимум в нескольких операциях процессора push*/pop* и call/ret при вызове с непосредственной адресацией. Если сам алгоритм htoi реализован хорошо, то таким образом можно добиться значительного процента прироста скорости работы. Если же реализовать виде виртуальных методов класса, то добавятся еще операции поиска по таблицам методов. Опять таки, при хорошей реализации htoi можно получить значительный процент замедления. Операция одна и та же. Аргументы и их формат одни и те же. Железо одно и то же. Скорость выполнения - разная. Почему ? > Так что там с делением текстовых строк? :) Кажись, двоично-десятичная логика x86 этим занималась. > Алгоритм, скажем, обратной трассировки луча с представлением данных в виде текста > не приведете? ;) Легко. Надо только его математику вспомнить :) Но это не скорость формата. Это скорость работы конкретной реализации конкретного алгоритма. > Мы говорим о точности формулировок или о том, с каким форматом операции > производятся быстрее? Мы говорим о том, что с одним и тем же форматом разные операции производятся с разной скоростью. И это не скорость формата. Это скорость конкретных операций в конкретных условиях. Это подвтерждает и попытка перейти с операции вывода на экран к операции трассировки луча. Объяснения того, каким образом отобразить бинарное представление (которое по Вашим словам заведомо "быстрее" всегда, везде и при любых условиях) быстрее строкового я так и не увидел.
	геймер 29 May 2006 5:59 PM
очередная PR акция от MS. Я вас наверно сильно огорчу, но вот кран ездит гараздо медленнее мерседеса. Надо все краны повыкидывать насвалку. Интересно, а кто нить осилит обьяснить внятно с чем связана разница в скоростях? И что вообще с чем сравнивали? "«Продуктов Open XML еще просто не существует, так что сравнивать не с чем, — сказал он. — А ODF поддерживают и используют не только OpenOffice, но и множество других приложений, включая StarOffice, IBM Workplace, KOffice, Abiword/Gnumeric и Google Writely. Все они демонстрируют разную производительность». Он добавил, что изначально OpenOffice.org не был оптимизирован для ODF, но со временем будет." ПОходу точно - гонки на кранах - катерпиллер быстрее камаза...
	Ender 29 May 2006 6:23 PM
Все спорят, а нет чтобы померять. Итак, результаты полученные для PIV 2.4GHz, Windows XP SP2, RAM 1Gb. Тестовый файл "Владычица озера" Сапковского с lib.ru. 980K чистого текста. MS Word 2003: запись в XML - ~1 сек, получился файл ~2.8Mb, чтение его-же: ~1 сек. OpenOffice Writer: запись в ODT ~5сек, получился файл 640K, чтение его-же: ~4 сек. При попытке как записать так и прочитать Writer-ом файлы в формате Microsoft Word 2003 XML, Writer вставал колом. 100% CPU, стабильное заедание памяти по паре мегабайт в секунду. Я дожидался пока он не съест половину и вырубал его. Вывод: статья правдива.
	Ender 29 May 2006 6:35 PM
2Shamlo: "Здесь важно определить какие мы имеем ввиду операции. Если операции открытия документа... то как вам такой аргумент? Операция открытия документа в майкрософтовском XML-формате в OpenOffice.org вообще не производится, т.е. ее скорость равна нулю." :-)))) Shamlo в своем репертуаре. Операция открытия MS Word XML опеноффисом имеет отрицательную скорость. :-) Т.е. он показывает будто открывает файл, а на самом деле просто жрет CPU, безо всяких результатов. Т.е. эта шволочь еще и тратит мое время! 2A: "Хорошо. Какой формат числовых данных "быстрее" - бинарный или текстовый ?" Для одинаковой задачи, для одних и тех-же данных, текстовый медленнее. Ровно на то количество ресурсов которое потребуется чтобы: 1 - прочесть его, 2 - преобразовать во внутренние структуры приложения.
	Serg 29 May 2006 6:39 PM
winjtermute, пожалуйста, не передергивайте. "Так что там с делением текстовых строк? :) Алгоритм, скажем, обратной трассировки луча с представлением данных в виде текста не приведете? ;)" - Вы прекрасно понимаете, что это из другой оперы. И на всеобщность никто не замахивался.
	Ender 29 May 2006 6:54 PM
Второй тест на той-же машине. Достал какой-то старый курсач: doc 1.4Mb 58 стр, текст разными стилями, всякая разная графика, схемы и т.п. Writer, ODT: сохранение ~7 сек, чтение ~5 сек Word, XML: сохранение ~2 сек, чтение ~2 сек Вот блин! И тут Word быстрее.
	Bilbo - chelyabinfromru.com 29 May 2006 6:58 PM
Посмотрел спецификации и примеры на оба формата. Абсолютно согласен с товарищем Марчичем (см. статью), MS изобретает колесо. Интеграции с текущими стандартами W3C нет. ODF с ними совместим и активно их использует. Еще одно наблюдение: MS судя по всему "зашивает" некоторые предположения по структуре и данным документа в софт, что (может быть) позволит им повысить эффективность, но нивелирует фундаментальное качество XML - самоописываемость.
	A 29 May 2006 7:02 PM
2 Ender: > Для одинаковой задачи, для одних и тех-же данных, текстовый медленнее. Гм... Еще раз. Имеем одну задачу - вывести на экран в понятном для пользователя виде число, представленное в одном случае строкой, а в другом случае - бинарным форматом архитектуры железа. В каком случае мы сделаем это быстрее при условии, что алгоритмы реализации в обоих случаях реализованы идеально ? > 2 - преобразовать во внутренние структуры приложения. О ! Хоть кто-то вспомнил про внутренний формат приложения :) > Вывод: статья правдива. Неверный вывод. Сравнение скорости импорта/экспорта различных форматов в различных программах. Ни одной точки соприкосновения между результатами не наблюдается. Вывод: что вообще сравнивалось ? Даже если считать это сравнение верным, то можно сказать, что формат OpenXML очень "медленный" и "прожорливый к памяти", поскольку OOo его открывал очень долго и тяжко. Логично ? Делая подобные сравнения я могу смело утверждать, например, следующее: формат GIF, открываемый в Netscape, "медленнее" формата PNG, открываемого в IE. Или наоборот - смотря какие циферки получатся.
	VicTor 29 May 2006 9:50 PM
2 A: > Имеем одну задачу - вывести на экран в понятном для пользователя виде число, представленное в одном случае строкой, а в другом случае - бинарным форматом архитектуры железа. > В каком случае мы сделаем это быстрее при условии, что алгоритмы реализации в обоих случаях реализованы идеально ? Если взять в руки букварь и вспомнить, что для десятичной арифметики в x86 используются два формата - десятичный упакованный и десятичный неупакованный, то ответ на ваш вопрос будет один - конечно, в десятичном неупакованном :)
	Shamlo 29 May 2006 10:16 PM
> Ender: :-)))) Shamlo в своем репертуаре. Операция открытия MS > Word XML опеноффисом имеет отрицательную скорость. :-) Т.е. > он показывает будто открывает файл, а на самом деле просто > жрет CPU, безо всяких результатов. Т.е. эта шволочь еще и > тратит мое время! Ну, типа, намек понятен. ОпенОфис - плохой софт, так как он не поддерживает XML-формат от Майкрософт. Хорошо, засчитываем один камень в огород ОпенОфиса. Преходим к форматам. XML-формат от Майкрософта правильно поддерживается только в софте от самого Майкрософта. И это уже камень в огород непосредственно формата. Причем в данном контексте значение имеет только камень, брошенный в огород формата, так как речь идет именно о форматах, а не о софте. > Writer, ODT: сохранение ~7 сек, чтение ~5 сек > Word, XML: сохранение ~2 сек, чтение ~2 сек > > Вот блин! И тут Word быстрее. Спору нет. Но так-ли это важно в наше время, когда компьютеры быстры, а файлы у большинства юзеров малы?
	A 29 May 2006 11:26 PM
2 VicTor: > Если взять в руки букварь [skiped] А если всё-таки почитать букварь, а не только взять его в руки ? :)
	VicTor 29 May 2006 11:40 PM
2 A: Ну вот и почитайте :) И уясните разницу между бинарным форматом ЧИСЕЛ и десятичным, а также между двоичным и символьным представлением :)))
	A 30 May 2006 3:57 AM
2 VicTor: Ну давайте вместе читать и уяснять разницу. Для начала определимся с тем, что мы говорим об одном и том же - "десятичный неупакованный" формат это то, что у нас называлось двоично-десятичной логикой, которую я уже упоминал. То есть, одна тетрада бит (половина октета) представляет собой одну десятичную цифру (0-9) вместо одной шестнадцатиричной цифры (0-16, 0x0-0xF). Таким образом, число 1234 в 16-битном регистре будет выглядеть, как 0x1234, а не 0x04D2. Мы говорим об одном и том же ?
	sukinkot 30 May 2006 5:19 AM
Насколько я понимаю, скорость работы с OD снижается из-за того, что формат сжатый (экономия места, тоже плюс, если я не ошибаюсь). + разработчики OOo утверждают, что модуть поддержки OD еще не "отпалирован", и якобы когда это произойдёт работа с этим форматом должна ускориться. Поживём увидим. 2Ender >При попытке как записать так и прочитать Writer-ом файлы в формате Microsoft Word 2003 XML, Writer вставал колом. 100% CPU, стабильное заедание памяти по паре мегабайт в секунду так мы всё-таки сравниваем скорость работы форматов или качество импорта неродного формата опенофисом?
	sukinkot 30 May 2006 5:21 AM
...упс. "сравниваем" читай "оцениваем" :-)
	VicTor 30 May 2006 8:04 AM
2 A: Нет. Это, как раз, УПАКОВАННЫЙ десятичный. Кроме того, для хранения в памяти в десятичном формате принят "прямой код", т.е. данные хранятся в виде цепочки байтов. Могу и более подробно...
	Ender 30 May 2006 8:48 AM
2А: "Имеем одну задачу - вывести на экран в понятном для пользователя виде число, представленное в одном случае строкой, а в другом случае - бинарным форматом архитектуры железа. В каком случае мы сделаем это быстрее при условии, что алгоритмы реализации в обоих случаях реализованы идеально?" А че уж так мелко-то? Давай мы это число в бинарном формате еще и зашифруем и положим на ленточный носитель. Если нам нужно только показать его, не производя никаких вычислений, то представление этого числа в бинарном формате будет ровно таким-же какое оно в текстовом. 2A: "Делая подобные сравнения я могу смело утверждать, например, следующее: формат GIF, открываемый в Netscape, "медленнее" формата PNG, открываемого в IE. Или наоборот - смотря какие циферки получатся." Да кто мешает-то. Пожалуйста утверждайте. Вопрос состоит в том (я кажется начинаю повторяться) что размещение данных в файле не совпадает с тем как они должны быть расположены во внутренних структурах программы. Если их соответствие хорошо продумано, то значит формат подходит для данного приложения, если не продумано, то не подходит. Причем речь идет даже не text vs binary, а продуманность vs непродуманность. Например, мне доводилось сталкиваться с форматом в котором данные были закодированы в виде битового потока с произвольной длиной записей в битах причем безо всякого выравнивания на границу байта или слова, и при чтении файла приходилось производить нешуточные телодвижения, для определения что-же мы читаем и сколько нам надо прочитать дальше. Получалось что в среднем на каждые 5..7 прочитанных бит приходилось производить некие вычисления, иначе прочитать файл было невозможно. Я вполне допускаю что структура файлов MS Word XML более ориентирована именно на организацию хранения текстов, а не вообще всего что только возможно.
	Ender 30 May 2006 8:51 AM
2sukinkot: "так мы всё-таки сравниваем скорость работы форматов или качество импорта неродного формата опенофисом?" Это был просто ответ шамло, который утверждал что MS Word не читает файлы формата ODT, на что я ответил что OO.org тоже не читает Word XML.
	Wintermute - devnul.ru 30 May 2006 8:58 AM
2 Shamlo: Уважаемый Shamlo! Поскольку я имею некоторый опыт, гм, ведение, гм, дискуссий с вами, я воздержусь от любых ответов на ваши комментарии. В конце концов, у меня пальцы - не казенные.
	Wintermute - devnul.ru 30 May 2006 9:09 AM
2 A: "Возьмем, к примеру, реализацию htoi в виде непосредсвенно кода в программе" А если все-таки вернуться к операции деления чисел, представленных в памяти в виде строк? Ой, я сомневаюсь, что самая худшая реализация htoi на компилируемом языке будет работать медленнее самой лучшей реализации целочисленного деления строк. Хотя нет, теоретически можно такое представить. Если кто-то разработает CPU, заточенный под строково-списочные операции. С Lisp в виде машинного языка :) Мечта Столлмана, кстати... "Кажись, двоично-десятичная логика x86 этим занималась" Там немного другая система была, 80 бит на число, байти разбиты на нибблы, каждый ниббл хранит цифру от 0 до 9, все, что больше вызывает ошибку. "Но это не скорость формата. Это скорость работы конкретной реализации конкретного алгоритма" ... Которая будет напрямую зависеть от внутреннего представления (формата) данных. А вот как раз операции, в математическом смысле, над этими данными будут одними и теми же. Да что мы спорим, вот мне в голову пришла формула Вирта: "Алгоритмы + структуры данных = программы". "Объяснения того, каким образом отобразить бинарное представление... быстрее строкового я так и не увидел" А я ведь сказал. Один параметр - размер. Число в двоичном формате занимает меньше места, следовательно, что его пересылка через стек/регистр, что из кэша в ALU и обратно бдет осуществляться быстрее, чем пересылка блока данных переменной длины (строки). Процессор заточен на выполнение элементарных операций с бинарными данными, а не со строками. Ну, и так далее.
	Wintermute - devnul.ru 30 May 2006 9:13 AM
2 Serg: Где я передергиваю? Г-н A задал провокационный вопрос, я на него ответил. Хотя ответ очевиден, он и ряд других господ начали меня убеждать, что бабушка надвое сказала, и строки могут быть эффективнее для обработки/хранения/передичи числовых данных. Очевидно, что при определенных граничных условиях это может быть так. Очевидно, что в общем случае это не так. Трассировка луча - хороший пример, это доказывающий. И?
	VicTor 30 May 2006 9:14 AM
2 Ender: > Если нам нужно только показать его, не производя никаких вычислений, то представление этого числа в бинарном формате будет ровно таким-же какое оно в текстовом. А что такое текстовый формат числа? Если мне не изменяет память, то в архитектуре процессоров существует только бинарный, десятичный, с плавающей точкой и символьный форматы.
	Ender 30 May 2006 9:39 AM
2VicTor: "А что такое текстовый формат числа?" Полагаю A подразумевал под ним запись числа как обычного текста. Т.е. число 123 записывается строкой "123". Собственно запись чисел в таком формате пригодна только для отображения их пользователю, ну и для полнотекстового поиска наверное.
	Shamlo 30 May 2006 9:39 AM
> Ender: Это был просто ответ шамло, который утверждал что MS > Word не читает файлы формата ODT, на что я ответил что OO.org > тоже не читает Word XML. Но ситуация-то не симметричная. На первый взгляд, все вроде бы одинаково: каждый пакет поддерживает один из форматов и не поддерживает другой. Но!... MS Office поддерживает свой частный формат (пусть и открытый) и не поддерживает утвержденный стандарт ISO, а OO.org поддерживает стандарт и не поддерживает частный формат конкурента. Сечёте в чем нюанс? У одного из них "нос в _жопе_", а у другого "_нос_ в жопе". > Wintermute: > 2 Shamlo: Уважаемый Shamlo! Поскольку я имею некоторый опыт, > гм, ведение, гм, дискуссий с вами, я воздержусь от любых > ответов на ваши комментарии. В конце концов, у меня пальцы - > не казенные. Хмм... ну я, в общем, не возражаю...
	VicTor 30 May 2006 10:00 AM
2 Ender: > 2VicTor: "А что такое текстовый формат числа?" > > Полагаю A подразумевал под ним запись числа как обычного текста. Т.е. число 123 записывается строкой "123". Собственно запись чисел в таком формате пригодна только для отображения их пользователю, ну и для полнотекстового поиска наверное. Ааааа... Ну, если так, то ответ на исходный вопрос: "Имеем одну задачу - вывести на экран в понятном для пользователя виде число, представленное в одном случае строкой, а в другом случае - бинарным форматом архитектуры железа. В каком случае мы сделаем это быстрее при условии, что алгоритмы реализации в обоих случаях реализованы идеально ?" будет однозначен - конечно, строка будет выведена быстрее - пуляй себе в порт по-байтно (или в видеопамять) :)))
	Ender 30 May 2006 10:05 AM
2Shamlo: "Но ситуация-то не симметричная." ISO - это кто такие? :-) Хоть трижды обзови ODT стандартом, хоть каких бумажек напридумывай, а возьми дискетку с файлом в этом формате, встань на улице, зайди в 10 первых попавшихся фирм и попробуй прочитать этот документ хотя бы в одной, не привлекая толпу ИТ спецов. Тогда быстро поймешь цену этому "стандарту". Действительно ситуация несимметричная. У одних, не смотря на то что стандарт и все такое, нос в жопе, а у других все работает и никаких проблем с чтением документов.
	VicTor 30 May 2006 10:15 AM
2 Ender: > ISO - это кто такие? :-) Это, как бы, Центр Стандартизации и Метрологии в масштабах Европы, а может быть уже и в больших :) И госучереждениях без его сертификата делать нечего...
	Ender 30 May 2006 10:23 AM
2VicTor: "И госучереждениях без его сертификата делать нечего..." Это точно не про Россию. И точно не про Австралию. Зато доки в DOC принимают на ура. Про другие страны не в курсе, хотя предполагаю что там все так-же. Стандарты ISO, вещь типа хорошая, но это еще не означает что она применимая. Много-ли вы знаете организаций, сертифицированных по ISO-9000 и его наследникам? А по сравнению с общим числом организаций? Переписку по почте вы в каком формате ведете, наверное тоже ISO, или все таки какой-нить KOI8-R?
	геймер 30 May 2006 10:39 AM
Блин, а в ASCII буква "А" занимает меньше памяти чем в Юникоде -> следовательно работает Юникод медленнее -> фтопку Юникод. ППЦ народ... о чем спорим...
	VicTor 30 May 2006 10:43 AM
2 Ender: > Стандарты ISO, вещь типа хорошая, но это еще не означает что она применимая. Очень применимая, вплоть до появления лозунгов: "Спробуй вино свободи!" :)))
	straus 30 May 2006 11:29 AM
2геймер здесь немного не так, это вроде как сравниваются два юникода
	straus 30 May 2006 11:32 AM
2Ender >>Стандарты ISO, вещь типа хорошая, но это еще не означает что она применимая. зря Вы так, именно благодаря стандартам (читай унификации) Вы можете вкрутить любой винт на М3 в любую гайку на М3
	straus 30 May 2006 11:50 AM
2Wintermute интересно если текстовое педставление такое не эффективное, от чего же оно столь популярно?
	Shamlo 30 May 2006 12:56 PM
> VicTor: Это, как бы, Центр Стандартизации и Метрологии в > масштабах Европы, а может быть уже и в больших :) И > госучереждениях без его сертификата делать нечего... Более того, влияние многих стандартов распространяется далеко за пределы госучреждений. Например, вполне себе коммерческий банк не может применить в своем собственном софте любой алгоритм шифрования, а вынужден использовать только лишь те, которые являются стандартными и сертифицированы соответствующими органами. При этом алгоритм, разработанный банком в собственных секретных лабораториях, может быть умопомрачительно быстр и столь же крут, этот факт ничуть не увеличит его шансы на внедрение.
	Ender 30 May 2006 1:26 PM
2straus: "интересно если текстовое педставление такое не эффективное, от чего же оно столь популярно?" А с чего вы взяли что оно популярно? С того что в линуксяче/юниксячей среде, где традиционно не хватает рук/терпения/желания/умения, вместо окошечка с настройками традиционно-же предлагается поредактировать текстовый файлик? Сейчас, в современных дистрах, все больше делается через GUI, но началось то все оттуда.
	Ender 30 May 2006 1:45 PM
2Shamlo: "При этом алгоритм, разработанный банком в собственных секретных лабораториях, может быть умопомрачительно быстр и столь же крут, этот факт ничуть не увеличит его шансы на внедрение." Увеличит. Только для этого надо сперва этот алгоритм придумать, а потом еще и обосновать что он быстр и крут, что наверняка столь-же затратно как его станартизация и сертификация через всевозможные учреждения. Самое главное - насколько легко соответствовать этому стандарту. Например некая государственная контора объявляет тендер на разработку какого-то софта, одно из условий - поддержка стандартов A,B,C,D. Если это простые стандарты, т.е. легко поддающиеся поддержке, то ради бога, кое кто из разработчиков успевает написать поддержку стандарта, если нет, то многие, подходящие по прочим параметрам оказываются за бортом, а остаться могут те, которые стандарт поддерживают хорошо, но при этом основную задачу выполняют посредственно. При этом наличие тех или иных стандартов в списке требуемых, мягко говоря, бывает совершенно неоправданным и не нужным. Особенно "радует" еще вот какой подход. Требуется совместимость с неким форматом сертифицированным каким-нить NIST или ISO, при этом всех вполне удовлетворяет то что сама система работает с документами собственного формата, а в эти форматы производит только экспорт или импорт. Система сдана. Проходит год, второй, и выясняется что за два года требуемой функциональностью ни разу не воспользовались. На третий год выясняется что реалии несколько другие, назаключали разных соглашений из которых проистекает то что нужно доработать систему чтобы она вела обмен файлами в са-а-а-всем других форматах... Стандартизация ODT ISO это конечно хорошо, но этого недостаточно чтобы ODT стал широко используемым. Я даже могу подсказать рецепт его популяризации - использование в продуктах Microsoft, но OpenSource Community так долго поливает грязью Microsoft, что сие сомнительно, а вот доминирование Office XML на рынке в последующие пару лет вполне вероятно.
	xacid 30 May 2006 2:08 PM
редактировать текстовый файлик - это архиправильно потому как редактировать текстовый файлик в окошке с настройками - можно и даже раз плюнуть а вот наоборот - в текстовом файле редактировать окошко с настройками - никак, практически не реально вот почему редактируются текстовые файлики, а не потому что лень вы видимо считаете что окошечки это панацея ан нет текстовые файлики вобще могут редактироваться нечеловеками программами разными например с окошками намного хуже будет
	straus 30 May 2006 2:09 PM
эх, Ender, плохо Вы тестировали xml формат файлов office2003 столь любимой Вами фирмы microsoft, ведь там полностью текстовое представление, причём даже для бинарных данных
	A 30 May 2006 2:33 PM
2 VicTor: > Нет. Это, как раз, УПАКОВАННЫЙ десятичный. [skiped] Тю ты блин. Ты имеешь ввиду фактически те же строки ? :) > будет однозначен - конечно, строка будет выведена быстрее - пуляй себе в порт > по-байтно (или в видеопамять) :))) Еще быстрее. Одной командой процессора :) - 2 Ender: > Если нам нужно только показать его, не производя никаких вычислений, то > представление этого числа в бинарном формате будет ровно таким-же какое оно в > текстовом. Интересное утверждение. То есть, скажем, тип int, хранимый в базе данных, хранится в виде последовательности байт, представляющей собой набор ASCII кодов каждой цифры ? > Да кто мешает-то. Пожалуйста утверждайте. А смысл ? > Если их соответствие хорошо продумано, то значит формат подходит для данного > приложения, если не продумано, то не подходит. Во. Здравая мысль. Это я на тему "для данного приложения". Это глобальная проблема формата ? Или же всё-таки это проблема конкретной связки формата и программы ? > А с чего вы взяли что оно популярно? Наверное с того, что в настоящий момент мы читаем текст, а не преобразуем наборы битов в буквы. Хотя если бы изначально алфавит строился в двоичной системе... :)
	A 30 May 2006 2:33 PM
2 Wintermute: > А если все-таки вернуться к операции деления чисел, представленных в памяти в виде > строк? А если всё-таки вернуться к тому, с чего началось ? К утверждению некоторых, что бинарный формат "быстрее" всегда, везде и при любых условиях. Я правильно понял смысл ответа от "29 мая, 2006, 14:31" ? Я так и не увидел описания процесса вывода на экран бинарного чила, который был бы быстрее вывода строки. Причем, не совпадал по скорости (в лучшем случае), а именно быстрее. Как только увижу, так и сразу. > Ой, я сомневаюсь, что самая худшая реализация htoi на компилируемом языке будет > работать медленнее самой лучшей реализации целочисленного деления строк. Речь шла не об этом. Речь шла о том, при одном и том же формате данных на одном и том же железе скорость работы htoi меняется при семене реализации самой функции. И меняется заметно. Если прочие условия равны, то... > Которая будет напрямую зависеть от внутреннего представления (формата) данных. Кроме этого она будет напрямую зависеть от своей собственной реализации, от методов адресации и представления информации в памяти, от быстродействия источника данных и т.д. Ender, кстати, сам того не желая (наверное) подтвердил мою позицию проведя "сравнение" между MSO и OOo. При одинаковом железе, одинаковых форматах, одинаковых данных скорость работы програм разная. Почему ? Если не совпадает только код программы, то почему должна меняться скорость обработки одного и того же формата ? > А я ведь сказал. Один параметр - размер. [skiped] > Процессор заточен на выполнение элементарных операций с бинарными данными, > а не со строками. Ну, и так далее. И что ? Каким образом я могу вывести на экран число 1234 закодированное стандартным двоичным кодом, с которым так удобно работать процессору и которое меньше своего строкового представления, на экран быстрее, чем строковое представление этого же числа ? Ведь утверждение о том, что этот формат всегда "быстрее" имело место. Я бы хотел увидеть подтверждение этому в данном конкретном случае. PS. И прежде чем переводить разговор на деление или трассировку, покажите, где я утверждал, что бинарный формат всегда "медленнее" строкового.
	straus 30 May 2006 2:34 PM
2Ender >>Увеличит. Только для этого надо сперва этот алгоритм придумать, а потом еще и обосновать что он быстр и крут, что наверняка столь-же затратно как его станартизация и сертификация через всевозможные учреждения. обосновывать, на мой взгляд, в данном случае, нужно будет, экономическую эффективность применения нового алгоритма, причём в рамках всей системы. Быстрота и крутость нового алгоритма ни кого не интересует, если принятый к использованию алгоритм справляется со своими задачами. Именно по этому интел всё ещё производит 386 процессоры.
	Wintermute - devnul.ru 30 May 2006 4:45 PM
2 straus: "интересно если текстовое педставление такое не эффективное, от чего же оно столь популярно?" Популярно где? Как я сам говорил ниже, у текстового представления есть преимущества, одно из которых - его можно редактировать руками.
	Ender 30 May 2006 4:46 PM
2straus: "эх, Ender, плохо Вы тестировали xml формат файлов office2003 столь любимой Вами фирмы microsoft, ведь там полностью текстовое представление, причём даже для бинарных данных" И?! Я утверждал где-то обратное? А вот то что ODT документ сохраняется 7 секунд, на современном ПК, это аргумент в пользу мокрософта, где всего 2 сек. 2A: "Интересное утверждение. То есть, скажем, тип int, хранимый в базе данных, хранится в виде последовательности байт, представляющей собой набор ASCII кодов каждой цифры?" Не так. Если стоит задача только выводить число и больше никаких других задач не стоит (т.е. нам никогда не понадобится, скажем сортировать эти числа, искать по ним что-то, производить вычисления и т.п.), при этом скорость вывода критична, и занимаемый числом объем памяти не критичен, то тогда есть смысл хранить число не в машинном бинарном формате, а текстовое представление этого числа. "Во. Здравая мысль. Это я на тему "для данного приложения". Это глобальная проблема формата ? Или же всё-таки это проблема конкретной связки формата и программы ?" Развиваем мысль дальше. Можно придумать такой формат, который подходит для хранения и текста, и электронных таблиц, и встроенной графики, и еще бог знает чего. При этом принципиально он будет оставаться тем-же XML-ем, или compound document-ом. При программа для работы с текстом будет работать с ним медленнее нежели другая программа, которая использует принципиально такой-же (XML), но организованный так что представление и организация данных в нем очень близко к внутреннему представлению и организации данных другой программы. Вот тесты налицо: OOo читает файлы своего собственного формата в 2..3 раза медленнее чем Office свои. Возможные причины: 1. OOo написан коряво. 2. Формат ODT придуман коряво, так что OOo приходится делать что-то, чего не приходится делать MS Office. Наверное, если поизучать внутренности, то можно докопаться до истины, в статье этого не написали, но если утверждают что корявый именно формат, то наверное так и есть.
	Shamlo 30 May 2006 4:52 PM
> Ender: При этом наличие тех или иных стандартов в списке > требуемых, мягко говоря, бывает совершенно неоправданным и не > нужным. Ну да. Так и есть. Мир несовершенен. Но к данному случаю это не очень-то и относится. Здесь речь про формат документов, которыми люди будут меняться друг с другом. Т.е. если формат будет поддерживаться только платным софтом, то бедные не смогут открывать такие документы, а значит использованием исключительно этого формата не смогут ограничиться даже богатые, которые пишут документы для бедных. При этом очевидно, что один формат для всех документов удобнее, чем два. Даже в том случае, если второй формат очень быстрый. В общем, "стандартизированная халява" зарулит любой формат, который требует платного софта. > а вот доминирование Office XML на рынке в последующие пару лет > вполне вероятно. Если это и произойдет, то точно не потому, что формат "быстрый", а только лишь потому, что антимонопольные органы опять не справятся со своей задачей.
	Wintermute - devnul.ru 30 May 2006 4:57 PM
2 A: "Я правильно понял смысл ответа от "29 мая, 2006, 14:31" ?" Да, правильно поняли. "Я так и не увидел описания процесса вывода на экран бинарного чила, который был бы быстрее вывода строки" Мы говорили об эффективности формата представления данных. Вывод на терминал бинарных данных обычно сопровождается _преобразованием_ формата с заведомой потерей эффективности. Если только мы не оговариваем, что речь идет числах в бинарном формате, представляющих собой индексы в палитре цветов или упакованые яркости разложений цвета в RGB, только тогда такие двоичные данные можно вывести на экран, не преобразовывая в текстовые (преобразования в бинарного формата в бинарный допускаем). Очевидно, что операция BitBlt в графическом режиме будет быстрее вывода текстовых строк. Вспоминается, как несколько лет назад кто-то предлагал хранить картинки в виде plain text. Было весело. "Речь шла о том, при одном и том же формате данных на одном и том же железе скорость работы htoi меняется при семене реализации самой функции. И меняется заметно" Это совершенно верно, но никак не касается формата обрабатываемых данных и его эффективности с точки зрения, например, занимаемого объема или эффективности передачи по проводам. "Кроме этого она будет напрямую зависеть от своей собственной реализации, от методов адресации и представления информации в памяти, от быстродействия источника данных и т.д." Совершенно верно. Но при прочих равных условиях стандартные операции над плавающими числами будут эффективнее, если они представлены в двоичном, а не текстовом формате. Только ручной ввод таких данных неэффективен - человеку проще работать с символами, а не битами. Насчет числа 1234 - см. выше, не хочу повторяться.
	A 30 May 2006 5:11 PM
2 Ender: > Наверное, если поизучать внутренности, то можно докопаться до истины, в статье > этого не написали, но если утверждают что корявый именно формат, то наверное так > и есть. Они не утверждают, что он корявый. Они утверждают, что он медленный. Однако же сам по себе формат скорости не имеет и иметь не может - это статический объект. Как, скажем, камень может быть медленным или быстрым ?
	A 30 May 2006 5:17 PM
2 Wintermute: > Мы говорили об эффективности формата представления данных. Вывод на терминал > бинарных данных обычно сопровождается _преобразованием_ формата с заведомой > потерей эффективности. Ну а как же тогда это соотносится с: "Да, правильно поняли" ? > Это совершенно верно, но никак не касается формата обрабатываемых данных и его > эффективности с точки зрения, например, занимаемого объема или эффективности > передачи по проводам. ЧТД
	Wintermute - devnul.ru 30 May 2006 5:19 PM
2 A: "Ну а как же тогда это соотносится с: "Да, правильно поняли" ?" Напрямую. Вы спросили - какой формат представления чисел эффективнее, текстовый или бинарный. Я ответил - бинарный, и обосновал. В вашем вопросе не содержалось ничего о _преобразованиях_ одного формата в другой. "ЧТД" Я рад, что вы, наконец, согласились со мною.
	A 30 May 2006 7:51 PM
2 Wintermute: > Напрямую. Вы спросили - какой формат представления чисел эффективнее, > текстовый или бинарный. Я спросил, какой формат числовых данных "быстрее" - бинарный или текстовый ? :) > В вашем вопросе не содержалось ничего о _преобразованиях_ одного формата > в другой. Конечно. Но в ответе тоже такого не наблюдалось. Было просто безапелляционное утверждение, что бинарный эффективнее всегда вне зависимости ни от чего. Как оказалось, всё зависит от програмно-аппаратного комплекса, с помощью которого решается задача, использующая данные в этом формате. > Я рад, что вы, наконец, согласились со мною. Ну изначально в этом у нас расхождений не наблюдалось. Я ж вопросом комментировал Ender-а
	Ender 30 May 2006 8:21 PM
2Shamlo: "Здесь речь про формат документов, которыми люди будут меняться друг с другом." Ключевое слово "будут". Второе ключевое слово, которое ты не упомянул "возможно". "Т.е. если формат будет поддерживаться только платным софтом, то бедные не смогут открывать такие документы, а значит использованием исключительно этого формата не смогут ограничиться даже богатые, которые пишут документы для бедных." Вот скажите, вам действительно важно чтобы ваш файл прочитал бедный негр? Вы действительно пишете документы для бедных? Вы не можете сделать простой текстовый файл, для бедных, которые не могут украсть MS Office? "При этом очевидно, что один формат для всех документов удобнее, чем два. Даже в том случае, если второй формат очень быстрый. В общем, "стандартизированная халява" зарулит любой формат, который требует платного софта." Самое главное чтобы оно работало в том объеме в котором это нужно. Лично я из всего офиса пользую две вещи - Visio, и проверку правописания Word-а. Это те два ключевых момента по которым OpenOffice.org попросту отсасывает у MS Office.
	Ender 30 May 2006 8:23 PM
2A: "Они не утверждают, что он корявый. Они утверждают, что он медленный. Однако же сам по себе формат скорости не имеет и иметь не может - это статический объект. Как, скажем, камень может быть медленным или быстрым ?" Очень даже может быть. В особенности если надо его бросить своей рукой.
	Shamlo 30 May 2006 9:26 PM
> Ender: Лично я из всего офиса пользую две вещи - Visio, и > проверку правописания Word-а. Это те два ключевых момента по > которым OpenOffice.org попросту отсасывает у MS Office. Забавно, но факт. Именно эти две вещи я вообще не использую. Visio вообще не ставлю. А проверку правописания просто отключаю. Она почти каждое мое предложение подчеркивает зеленым и нудит на ту тему, что оно, дескать, слишком длинное, и его надо разбить на несколько. Как будто я сам не знаю, какой длины предложения мне следует писать. А то, что она подчеркивает красным, вообще смешно. Либо это очевидная опечатка, которую я в любом случае замечу при вычитке, либо какое-нибудь название, которое написано абсолютно правильно, но она его просто не знает.
	Shamlo 30 May 2006 9:29 PM
> Ender: Очень даже может быть. В особенности если надо его > бросить своей рукой. О! А вот здесь пожалуйста поподробнее... Камень может быть "быстрым"? Не "быстро летящим", а именно "быстрым"?
	VicTor 30 May 2006 10:11 PM
2 A: >> 2 VicTor: >> Нет. Это, как раз, УПАКОВАННЫЙ десятичный. >[skiped] > > Тю ты блин. Ты имеешь ввиду фактически те же строки ? :) Видимо, вы разницы так и не поняли (цитирую букварь по канонической архитектуре x86, опуская форматы с плавающей точкой): а) бинарный формат - число в двоичном представлении в виде байта, слова, двойного слова и т.д. Для хранения в памяти используется так называемый "дополнительный код". На них ориентированы все команды арифметических операций процессора (add, div, mul, sub). б) неупакованный десятичный - в каждом байте в младшей тетраде хранится десятичная цифра от 0 до 9, старшая тетрада равна 0. Для хранения в памяти используется так называемый "прямой код", хранятся в виде цепочки байтов, длина, в принципе, неограничена. Поскольку ориентированных на них арифметические операций нет, то используются побайтово выполняемые команды арифметических операций для бинарных операндов с применением операций коррекции (aaa, aad, aam, aas). Накладные расходы на реализацию алгоритмом типа сложения или умножения "в столбик" предлагаю посчитать самим. в). упакованный десятичный формат - упомянут вами и Wintermute - в каждой тетраде байта хранится десятичная цифра от 0 до 9. Для хранения в памяти используется так называемый "прямой код", хранятся в виде цепочки байтов длиной 10 байт (байт с младшим адресом - знак). Используются только командами загрузки процессора с плавающей точкой. >> будет однозначен - конечно, строка будет выведена быстрее - пуляй себе в порт >> по-байтно (или в видеопамять) :))) > > Еще быстрее. Одной командой процессора :) Обнародуйте ж, жуть как интересно. Неужели что-то типа незабвенных SIO/TIO/HIO? :))
	VicTor 30 May 2006 10:21 PM
2 Shamlo: > Т.е. если формат будет поддерживаться только платным софтом, то бедные не смогут открывать такие документы, а значит использованием исключительно этого формата не смогут ограничиться даже богатые, которые пишут документы для бедных. Да не интересует государство вопрос для кого этот формат - для богатых или бедных. Государство интересует вопрос контроля - кто будет контролировать разработку, использование и развитие формата - государство или Вася Пупкин...
	A 30 May 2006 10:33 PM
2 VicTor: http://www.atmel.ru/Articles/Atmel13.htm "Неупакованный десятичный код является подмножеством международной таблицы кодирования символов ASCII" Ну и там в таблица приведены коды символов. Кому верить ?... :) PS. ПОд рукой ни одного букваря на эту тему, кроме гугла :)
	Shamlo 30 May 2006 10:50 PM
> VicTor: Да не интересует государство вопрос для кого этот > формат - для богатых или бедных. Что интересует государство - это совсем другой вопрос. Разумеется, ему хочется контролировать абсолютно все, но кто же ему это позволит. Моя мысль про бедных и богатых была высказана к тому, что время форматов, обязывающих покупать дорогой софт, безвозвратно ушло. Пока у бедных вообще не было компьютеров, законодателями мод на форматы были компании, разрабатывающие дорогой софт. Но эти времена прошли. Железячники уже осчастливили компьютерами всех богатых и теперь сосредоточили усилия на бедных. А у них денег хватает только на сами компьютеры, на софт просто не остается. Поэтому преимущества чисто платных форматов не играют вообще никакой роли. Вопрос о покупке софта бедными даже не рассматривается (при наличии бесплатных альтернатив), поэтому доминирование бесплатных форматов в будущем просто неизбежно. Богатые могут сопротивляться, но это не поможет. Цимус в том, что бедных в разы больше, и они являются основнымм потребителями контента, а значит в конкурентной борьбе победят форматы удобные именно им, какими бы плохими и "медленными" они не были.
	Koshevinn - koshevoi.batrubimail.ru 31 May 2006 5:58 AM
Хотел бы поблагодарить за интересный сайт, и в целом, очень полезный.
	Ender 31 May 2006 7:41 AM
2Shamlo: Я понимаю что для тебя сейчас создался уникальный шанс прицепиться к словам и заняться выяснением может камень быть быстрым или нет. Может. Точно так-же как он может быть тяжелым, зеленым, противным и т.п. При каких условиях камни будут различать на быстрые и медленные, додумайся сам, ты у нас специалист по созданию фантастических теорий.
	VicTor 31 May 2006 8:00 AM
2 A: > http://www.atmel.ru/Articles/Atmel13.htm [...skip...] > Ну и там в таблица приведены коды символов. > Кому верить ?... :) Да и такое практикуется :) Автор только забыла упомянуть, что кроме ASCII-формы неупакованного десятичного, существует ещё EBCDIC-форма (коды от 0xF0 до 0xF9). Кроме того, перед выполнением арифметических операций старшую тетраду всё таки рекомендуется обнулить, а операции коррекции как раз возвращают чистый неупакованный BCD с нулевой старшей тетрадой. > PS. ПОд рукой ни одного букваря на эту тему, кроме гугла :) Смените непечатный букварь на печатный :) Или "щитильнее, надо быть, щитильнее" (с)Жванецкий :) Тогда можно найти, например: http://www.osdata.com/topic/language/asm/bcdarith.htm
	VicTor 31 May 2006 8:16 AM
2 Ender: > При каких условиях камни будут различать на быстрые и медленные, додумайся сам, ты у нас специалист по созданию фантастических теорий. Ааааааа!!!... Ржунимагу!!!... Т.е. нести всякую х@#ню будете вы, а обосновывать её должен Shamlo?
	Ender 31 May 2006 9:05 AM
2VicTor: "Ааааааа!!!... Ржунимагу!!!... Т.е. нести всякую х@#ню будете вы, а обосновывать её должен Shamlo?" Отмотай тред и посмотри кто про камни начал. :-) Тебе, кстати, такое-же задание... сможешь? Возвращаясь все таки к теме статьи. Натурные эксперименты произведены? Произведены. OOo по скорости чтения собственных файлов сосет? Сосет. Те утверждения в статье скорее правильные чем не правильные. Вот вы давайте, теперь обоснуйте что это не формат ODT такой корявый, а OpenOffice так фигово написан. Так и так, вот Word XML, вот ODT, вот для разбора ODT нужно сделать то-то, для разбора Word XML нужно сделать то-же самое. Стало быть форматы по сути одинаковые а во всем виновата кривизна OpenOffice. Вот в таком ключе обоснование. Прошу.
	Wintermute - devnul.ru 31 May 2006 9:15 AM
2 A: Все, я сдаюсь!
	Wintermute - devnul.ru 31 May 2006 9:16 AM
2 Ender: "OOo по скорости чтения собственных файлов сосет? Сосет." Так я об этом здесь же годжа два-три назад говорил, за что был закидан какашками (не тобой, ничего личного).
	Wintermute - devnul.ru 31 May 2006 9:18 AM
2 Ender: "вот для разбора ODT нужно сделать то-то, для разбора Word XML нужно сделать то-же самое" От себя добавлю: написание XSLT для преобразования одного в другое и обратно - рутинная задача. За что спасибо разработчикам XML, Office и OO.
	fi 31 May 2006 11:37 AM
> OOo по скорости чтения собственных файлов.. Так собственных или же ODT? Они вообще-то разные. Вы бы разобались сперва :)
	straus 31 May 2006 12:07 PM
2Wintermute о противостоянии бинарного с текстовым: ODT смешанный формат, в то время как Office 2003 XML формат чисто текстовый 2Ender внимательно читаем статью: "изначально OpenOffice.org не был оптимизирован для ODF, но со временем будет." и ещё, я свободно открыл документ Office 2003 XML формата в OOo 2.0.2 (размер 3+ мб), правда где-то за 30 сек
	Shamlo 31 May 2006 12:11 PM
> Ender: Возвращаясь все таки к теме статьи. Нет, тема статьи уже как бы не так интересна. Хочется окончательно раскрыть тему "быстрых камней". Я вот, например, искренне не понимаю, как камень может быть быстрым. Понимаю, как он может быть тяжелым или зеленым, но мне никак не удается представить себе быстрый камень. И это при моих-то способностях по созданию фантастических теорий.
	eXOR 31 May 2006 12:15 PM
Лежит на диске файл OpenDocument и проигрывает по скорости лежащему рядом файлу Open XML. Лежит и проигрывает. И так это нехотя делает. Лениво так. Кайфуя от своей нерасторопности.
	fi 31 May 2006 12:40 PM
Подведу итог :) Только что про тестировал открытия odt и doc (100 страниц текста со вставками) в ОО: doc 5.5 сек. odt 3.0 сек. И так, бинарный формат doc "отсосал (по Ender-у)" у текстого формата. Я так понимаю, у Wintermute анд Ender возразить нечего.
	fi 31 May 2006 12:45 PM
Впрочем сам ворд: doc 7.75 сек. xml(мсо2003) 11.23 сек. Справедливости ради, надо заметить, что ОО2 не поддерживает xml-мсо2003, но открывает как простой xml 5 минут (сам придумывает оформление? :-).
	Wintermute - devnul.ru 31 May 2006 1:14 PM
2 fi: А что, у Word и OO внутреннее представление doc совпадают? Не знал, не знал.
	A 31 May 2006 2:19 PM
2 Ender: > Отмотай тред и посмотри кто про камни начал. :-) Аналогию привел я :) Если у камня есть характеризующее его понятие "скорость", то она не должна зависеть ни от чего до тех пор, пока сам камень не изменяется. Бросили его, не бросили - она есть и она постоянна. Так же как его масса, например. Хотелось бы увидеть её численное выражение в м/с. > OOo по скорости чтения собственных файлов сосет? Сосет. Те утверждения в статье > скорее правильные чем не правильные. Угу. Еще раз. Берем файл file.jpg. Открываем его, скажем, в XNView - время открытия 1 сек. Берем этот же самый файл file.jpg. Открываем его в ACDSee - время открытия 3 век. Какой из файлов "медленнее" ? Тут хоть есть одна общая точка - файл один и тот же. А что сравнивали Вы - сказать трудно. - 2 eXOR: :) - 2 fi: Если следовать выводам Ender-а, то ты доказал, что doc - "медленный" формат :)
	fi 31 May 2006 3:01 PM
то Wintermute А какая разница? формат-то "медлений" ;) Мы же не будем разбираться при каких условиях :)))?
	Ender 31 May 2006 3:31 PM
2fi: "Так собственных или же ODT? Они вообще-то разные. Вы бы разобались сперва :)" Тот OOo который мне удалось скачать, предлагает ODT как формат по умолчанию. Как пользователю мне глубоко до фени что какой-то из 10..15 форматов находящихся в его выпадающем списке форматов считается более нативным чем ODT. "И так, бинарный формат doc "отсосал (по Ender-у)" у текстого формата." Я так понял что OOo просто не умеет открывать doc. Или открывает его специально медленно. А чо, вполне себе теория заговора. Чтобы не пользовались doc-ом как форматом для хранения документов. Ты бы привел что-ли за сколько этот DOC был открыт вордом, тогда бы и установили кто у кого отсасывает "по Ender-у".
	Ender 31 May 2006 3:44 PM
2A: "Если у камня есть характеризующее его понятие "скорость", то она не должна зависеть ни от чего до тех пор, пока сам камень не изменяется. Бросили его, не бросили - она есть и она постоянна. Так же как его масса, например. Хотелось бы увидеть её численное выражение в м/с." Вот говорят в разговорной речи про камень что он "тяжелый". Заметь не говорят что "у этого камня масса 100" кг. Что это значит? Это значит что человеку который его попытается поднять будет тяжело и неудобно. "Зеленый". Никто не говорит что "камень отражает световые волны длиной от ... до ...". Т.е. самим фактом утверждения что он тяжелый или зеленый подразумевается какой-то общепринятый подход определения этой характеристики. У нас камни по жизни лежат, а не летают, поэтому скорость их полета обычно не делят на быструю и медленную, и не клеят к ним характеристики "быстрый" или "медленный". Ну а вот для формата - его разбор программой, самая что ни на есть обыденная операция, скорость которой вполне может ассоциироваться с самим форматом.
	Ender 31 May 2006 3:48 PM
2A: "Хотелось бы увидеть её численное выражение в м/с" Кстати, ты недалек от истины. Была как-то статья в ТМ, в которой величины СИ были переведены в форму м^n/сек^m. :-)
	A 31 May 2006 4:22 PM
2 Ender: > Вот говорят в разговорной речи про камень что он "тяжелый". Заметь не говорят что "у > этого камня масса 100" кг. Что это значит? Это значит что человеку который его > попытается поднять будет тяжело и неудобно. Это значит, что выражается субъективная точка зрения говорящего, подразумевающая вес камня в тех условиях, в которых он (говорящий) этот вес оценивал. Причем, вычислить этот параметр возможно только при произведении над камнем некоей работы (подъем оного) или расчитав необходимые затраты на выполнение этой работы в конкретных условиях. Фактически, эти слова характеризуют работу, которая в свою очередь может изменяться. Если использовать систему рычагов, то один человек сможет поднять камень, весом в тонну "одной левой". Стоит заметить, что при этом масса камня не изменяется. > У нас камни по жизни лежат, а не летают, поэтому скорость их полета обычно не > делят на быструю и медленную, и не клеят к ним характеристики "быстрый" или > "медленный". Как это не летят ? Летят. Причем, с немаленькой линейной и угловой скоростью. > Ну а вот для формата - его разбор программой, самая что ни на есть обыденная > операция, скорость которой вполне может ассоциироваться с самим форматом. Обычно она ассоциируется с кодом программы, которая работает с данным форматом. Это, кстати, подтвердила твоя фраза: "Я так понял что OOo просто не умеет открывать doc. Или открывает его специально медленно".
	Ender 31 May 2006 4:28 PM
2A: "Обычно она ассоциируется с кодом программы, которая работает с данным форматом. Это, кстати, подтвердила твоя фраза: "Я так понял что OOo просто не умеет открывать doc. Или открывает его специально медленно". Я приводил пример медленного формата.
	Shamlo 31 May 2006 4:48 PM
> Ender: Ну а вот для формата - его разбор программой, самая что > ни на есть обыденная операция, скорость которой вполне может > ассоциироваться с самим форматом. Вот это совсем другое дело. Я называю это "чувство контекста". Либо это "моя школа" дает о себе знать, либо ты обладал этим чувством изначально (но зачем-то скрывал). В любом случае, если это чувство развито хорошо, то с терминами можно обращаться менее аккуратно. "Медленный камень" - это, конечно же, полная чушь... а вот "медленный формат" определенно находится в пределах допустимой погрешности.
	A 31 May 2006 5:28 PM
2 Ender: > Я приводил пример медленного формата. А почему тогда: "OOo просто не умеет открывать doc. Или открывает его специально медленно" ? Почему нет слов: "просто формат doc медленный" ? Фактически, ты характеризовал не формат, а программу, которая с ним работает.
	RIK 1 Jun 2006 3:41 AM
В англоязычной литературе по фотографии вполне обычно характеризовать объективы как "быстрые" и "медленные". И всем понятно, что это значит. Смысл понятия "быстрый" или "медленный" формат совершенно очевиден.
	Ender 1 Jun 2006 5:15 AM
2A: "Почему нет слов: "просто формат doc медленный" ? Фактически, ты характеризовал не формат, а программу, которая с ним работает." Потому что рядом есть пример который наглядно показывает что формат doc не медленный. Если один и тот-же файл две разные программы открывают с существенно разной скоростью, то то что одна из них (а не формат) медленная а другая быстрая - очевидно.
	Wintermute - devnul.ru 1 Jun 2006 9:51 AM
2 fi: "А какая разница? формат-то "медлений" ;)" Для начала, я официально заявляю, что сомневаюсь в приведенных цифрах. Даже OO 1.0 тормозил при открытии собственных файлов по черному, с OO 1.1 вообще стало невозможно работать с серьезными документами. Даже AbiWord на глаз подтормаживает по сравнению с MS Word (везде имеются ввиду "родные" форматы") на мегабайтных файлах практически без разметки (~10 активных стилей), но не так катастрофически, как OO. Это мой опыт, проверено примерно на десятке компов под Win2k/WinXP. Снес я его, правда, по другой причине. Так что мне очень хочется увидет этот самый "100 страниц текста со вставками", который открывается за 7.5 секунд. Для справки скажу, что неоднократно встречался с документами в 1 страницу, которые открывались минутами, а то и валили Word. Их "исправление" обычно занимает несколько секунд, после чего такие забавные свойства исчезают.
	Wintermute - devnul.ru 1 Jun 2006 9:57 AM
2 RIK: Кстати, а не ведем ли мы здесь спор о некорректной кальке с английского? Навроде "большой вкус Пепси"?
	Павел 1 Jun 2006 10:36 AM
2 Shamlo: >Например, вполне себе коммерческий банк не может применить в >своем собственном софте любой алгоритм шифрования, а вынужден >использовать только лишь те, которые являются стандартными и >сертифицированы соответствующими органами. При этом алгоритм, >разработанный банком в собственных секретных лабораториях, может >быть умопомрачительно быстр и столь же крут, этот факт ничуть не >увеличит его шансы на внедрение. Ой ли? В госучереждениях понятно. А про банки можете ссылочку какую дать на постановление, или хоть сказать чем это определяется (законом, конституцией или еще чем).
	Павел 1 Jun 2006 10:43 AM
2 Ender >но OpenSource Community так долго поливает грязью Microsoft, что >сие сомнительно, а вот доминирование Office XML на рынке в >последующие пару лет вполне вероятно. Да, но вспомните чем было обусловлено, нет не появление Office XML (мне кажется, что он появился чуть ли не с Office 97, ну может в следующим после 97), а заявление что в следующем офисе XML будет основным форматом. Именно наличием ODF. Ведь без ODF никто не смог бы сказать офису (то есть МСу), что его не будут использовать потому что его формат не стандартизирован. Так что польза от ODF все-таки есть. И немалая. То же самое с линуксом. Может он и отстой, и в ОСС сидят фанатики и крикуны (на самом деле там рулят деньги, бизнесмены и маркетологи), но кто знает как бы выглядела следующая версия виндов, офиса и эксплорера не будь линукса и мозиллы.
	Павел 1 Jun 2006 10:45 AM
2 Ender >>2straus: "интересно если текстовое педставление такое не >>эффективное, от чего же оно столь популярно?" >А с чего вы взяли что оно популярно? А как же XML, Unicode, веб сервисы, html?
	Ender 1 Jun 2006 11:05 AM
2Павел: "А как же XML, Unicode, веб сервисы, html?" Было бы странным, если бы текст, основная надобность которого - отображение пред ясны очи пользователя, хранился-бы как-то иначе чем текст. Оно не более популярно чем бинарное, зашифрованное, или упакованное представление. Важно думать где какое больше подходит, а не пихать что-то одно везде где только можно.
	Павел 1 Jun 2006 11:41 AM
2 Ender: >Было бы странным, если бы текст, основная надобность которого - >отображение пред ясны очи пользователя, хранился-бы как-то иначе >чем текст. Во-первых скажите это офису у которого формат документов до последнего остается бинарным. Во первых вы говорили именно о текстовом представлении: >>2straus: "интересно если текстовое педставление такое не >>эффективное, от чего же оно столь популярно?" Очевидно что в текстовом представлении не все можно отобразить. Как например откомпилированную программу в текстовом виде отобразить или фильм или картинку. То есть насколько я понимаю говорилось именно о том, что можно представить в текстовом виде, а можно и не в текстовом. К тому же XML и веб сервисы не предназначены для отображения в общем случае. А в третьих все это начинает напоминать демагонию в стиле Alexander S., который утверждал, что монополия - это хорошо. В принципе согласен, неплохо, но только для монополиста.
	Wintermute - devnul.ru 1 Jun 2006 12:50 PM
2 Павел: "Очевидно что в текстовом представлении не все можно отобразить. Как например откомпилированную программу в текстовом виде отобразить или фильм или картинку" Вообще говоря, можно, в UUE, XXE, BinHex, Base64. Собственно, в XML именно так двоичные данные и вставляют.
	A 1 Jun 2006 1:23 PM
2 Ender: > Потому что рядом есть пример который наглядно показывает что формат doc не > медленный. Где ? Я вижу рядом пример: "Только что про тестировал открытия odt и doc (100 страниц текста со вставками) в ОО: doc 5.5 сек. odt 3.0 сек." Наглядно показывает, что в одной и той же программе файлы разных форматов открываются с разной скоростью. Причем, формат doc открывается медленнее. Где циферки, показывающие, что ODF открывается медленнее DOC в одной и той же программе ? > Если один и тот-же файл две разные программы открывают с существенно разной > скоростью, то то что одна из них (а не формат) медленная а другая быстрая - > очевидно. О чем и речь :) А если две разных программы открывают два разных формата с разной скоростью ? Это вообще о чем-нибудь говорит ? А если одна и та же программа открывает два разных формата с разной скоростью - о чем это говорит ?
	Wintermute - devnul.ru 1 Jun 2006 1:55 PM
2 Павел: С вашими мыслями насчет того, что OSS подталкивает MS и остальных полностью согласен. Они надоедливы, как весенние мухи, но а) в OSS есть несколько продуктов, которые просто брильянты и б) без них хуже, чем с ними.
	Alexander S. Kharitonov 1 Jun 2006 2:33 PM
2 RIK: > Смысл понятия "быстрый" или "медленный" формат совершенно очевиден. Если бы речь шла о принципиально различающихся форматах (например в одном - простой текст, а в другом - сжатый и зашифрованный), тогда бы смысл был. Однако когда мы говорим о двух XML-документах, высказывание "формат быстрее" звучит крайне сомнительно.
	Shamlo 1 Jun 2006 4:51 PM
> Павел: Ой ли? В госучереждениях понятно. А про банки можете > ссылочку какую дать на постановление, или хоть сказать чем это > определяется (законом, конституцией или еще чем). Определяется законом. И банки только лишь частный случай. В общем же случае иметь сертификат ФАПСИ на алгоритм шифрования должна любая контора, для которой шифрование является частью бизнес-процесса. Грубо говоря, чтобы иметь право говорить своим клиентам "мы тут кое-что шифруем", необходимо получить от ФАПСИ подтверждение того, что имеет место именно шифрование, а не какое-нибудь очень похожее на него действие.
	Павел 1 Jun 2006 6:39 PM
2 Wintermute: >Вообще говоря, можно, в UUE, XXE, BinHex, Base64. Собственно, в >XML именно так двоичные данные и вставляют. Вообще говоря я знаю про существование UUE и Base64. Мы же не про это говорили. Мы говорили про текстовое отображение текстовых данных :). Ну например число можно представить в двоичном виде или в текстовом. Группу парамтров (например настройку программы) можно представить в текстовом виде и в двоичном. Как картинку то в текстовом виде представить? То есть представить ее так, чтобы можно было ее понять просматривая текст? Аски кодами нарисовать? Хотя тут вроде был подобный спор на тему "что такое текст"... Смысл спорить то - мы ж про другое говорили. Ендер сказал, что текстовый формат не популярен. А я говорю - популярен :). 2 Shamlo: >Определяется законом. И банки только лишь частный случай. В общем >же случае иметь сертификат ФАПСИ на алгоритм шифрования должна >любая контора ... Ну да, я про это и хотел спросить - каким законом то? Про гос учереждения все понятно - есть информация ДСП, есть секретная и сов.секретная. Есть закон, где регламентируется как и где можно с этой информацией работать. Как эту информацию передавать. Есть ГОСТы на алгоритмы шифрования. Есть всякие вербы. Но это для ДСП. Ну короче хотя бы приблизительное название этого закона дайте, я попробую поискать для общего развития в каком нибудь консультанте или гаранте.
	straus 1 Jun 2006 8:10 PM
2Павел незнаю как внутри банка (скорее всего для внутренего документооборота можно пользоваться чем угодно), но для обмена данными с РКЦ необходимо использовать только системы основанные на сертифицированных ФАПСИ средствах шифрования. Так по крайней мере было года 3 назад.
	Shamlo 1 Jun 2006 11:03 PM
> Павел: Ну короче хотя бы приблизительное название этого закона > дайте, я попробую поискать для общего развития в каком нибудь > консультанте или гаранте. Откуда я знаю название закона? Я же не юрист. Просто работал одно время в конторе, которая разрабатывала софт для банков. До того как получили сертификат ФАПСИ не могли продукт даже на выставке выставить. О нем нельзя было официально заявить то, что он поддерживает шифрование. А уж о том, чтобы начать его продавать без сертификата, даже и мыслей не было. > straus: незнаю как внутри банка (скорее всего для внутренего > документооборота можно пользоваться чем угодно) Разумеется, для внутреннего использования можно применять что угодно... хоть Код Цезаря. На свой страх и риск. Да и не узнает никто.
	RIK 2 Jun 2006 1:49 AM
2 Wintermute >Кстати, а не ведем ли мы здесь спор о некорректной кальке с английского? Навроде "большой вкус Пепси"? Возможно, что-то в этом есть. В (американском) английском слова "slow" и "fast" используются в весьма расширительных толкованиях. "Fast" - не только "быстрый", но и позволяющий что-то делать быстро. Скажем, быстрый объектив - это тот, который при прочих равных позволяет поставить меньшую (более быструю) выдержку (т.е. более светосильный). Впрочем, и в русском языке говорят, например, "быстрая машина", хотя сама машина может в это время стоять. Замечу еще, что слово "fast" употребляется в смысле "совершенный, превосходный", а "slow" - в смысле "скучный". Однако в оригинальной статье идет речь именно о производительности. 2 Alexander S. Kharitonov >Если бы речь шла о принципиально различающихся форматах (например в одном - простой текст, а в другом - сжатый и зашифрованный), тогда бы смысл был. Однако когда мы говорим о двух XML-документах, высказывание "формат быстрее" звучит крайне сомнительно. Спор почему-то зашел о корректности термина "быстрый формат" - при том, что смысл его вполне ясен. Могут ли два XML формата кардинально отличаться по скорости (что значит в данном контексте "отличаться по скорости", я думаю, всем понятно?) - другой вопрос, который действительно интересно было бы обсудить. Точнее, не этот вопрос (ответ на который - конечно, могут), а то, чем различаются OpenXML и ODF в смысле производительности.
	RIK 2 Jun 2006 1:56 AM
P.S. Видел сегодня забавную рекламу в автобусе: "Stop giving a bully your lunch money. OpenOffice.org".
	Wintermute - devnul.ru 2 Jun 2006 9:23 AM
2 RIK: "В (американском) английском" В британском (по крайней мере) та же фигня. "а "slow" - в смысле "скучный" А так же "тупой" :) Великий могучий...
	Wintermute - devnul.ru 2 Jun 2006 9:25 AM
2 RIK: "Stop giving a bully your lunch money. OpenOffice.org" No, thanks, I'd prefer a program written by professionals. I like MS Word (I don't mind to pay for it) and AbiWord 2 (it's clumsy and a bit ugly, but at least it works). OO used to have a nice HTML editor though.
	Угрюмый anonymous 2 Jun 2006 11:38 AM
2 Wintermute > I'd prefer a program written by professionals. Ага вон вынь2к цельных 2000 профессионалов писали, и ещё столько же держали, чтоб не упала.
	Wintermute - devnul.ru 2 Jun 2006 4:58 PM
2 Угрюмый anonymous: Ха. Ха. Ха. Люникс пишут миллионы, а все говно говном.
	RIK 2 Jun 2006 9:42 PM
Wintermute >А так же "тупой" :) Великий могучий... Угу. В русском, кстати, есть аналог - "тормоз" :)
	tstone - saldomail.ru 4 Jun 2006 9:52 AM
Ну технически вполне возможно, что одна и таже операция выполняется при использовании одного формата быстрее, чем другого. И именно из-за _формата_. Почему? Ну, например, потому что в одном формате предусмотренно больше метаданных, позволяющих быстрее выполнить эту операция (например, индексирование). При этом скорее всего, на другой операции выйграет другой формат, так как "ничто не исчезает в никуда и не возникает из ниоткуда". Просто, если замедление этой операции станет действительно критическим, то наверняка что-нибудь придумают и модифицируют этот формат :-) Но майкрософт не был бы майкрософтом, если бы не попытался раздуть из этого слона. Люди же в массе своей не станут разбираться что там к чему на самом деле и поверит :(
	Павел 4 Jun 2006 10:50 PM
Shamlo >До того как получили сертификат ФАПСИ не могли продукт даже на >выставке выставить. О нем нельзя было официально заявить то, что >он поддерживает шифрование. А уж о том, чтобы начать его >продавать без сертификата, даже и мыслей не было. Это на мой взгляд естественно. А как по другому? Допустим вы продаете софт, который осуществляет шифрование. Но насколько это шифрование хорошо? И наколько оно реально все шифрует. Кто гарантирует, что злобный хацкер не взломает шифр и что в программе и в алгоритме нет никаких закладок? Правильно - единственной организацией в россии для этого дела является ФАПСИ (насколько я знаю уже несуществующая как отдельная организация). Это примерно как сертификат контроля качества - вы же не можете молоко продавать в магазине или лекарство в аптеке, если у вас нет на продукцию сертификата. И это правильно на мой взгляд (обязательная сертификация продуктов питания и лекарственных средств) - хоть какая то гарантия для граждан, что купив пакетик молока не отравишься. Граждане за это деньги кстати платят (за гарантии). Другое дело, что это часто не работает. Хотя говорят за проданное прокисшее молоко магазин могут так вздрючить, что им легче тыщу рублей вам лично заплатить. И другое дело что по слухам контора всегда для себя лазеечку оставляет. Я слышал, что какой то более защищенный адгоритм они завернули именно из-за того, что там не было лазеечки. Но это слухи, спорить не берусь, так озвучил - чисто на форуме. >Разумеется, для внутреннего использования можно применять что угодно Это ключевая фраза :). Я то думал, что кам в коммерческом банке что то запрещали использовать потому что у продукта не было сертификата, а вам оказывается запрещали продавать без сертификата. И даже не продавать запрещали, а запрещали говрить, что вы продаете средство защиты.
	Shamlo 5 Jun 2006 8:57 AM
> Павел: И даже не продавать запрещали, а запрещали говрить, > что вы продаете средство защиты. Ну когда ты разрабатываешь банковский софт, то он подразумевает криптозащиту. Поэтому если ты не можешь ей похвастаться, то твой софт ни одному банку не будет нужен. Стандарт на форматы документов может играть похожую роль, если правильно придумать законы. Например, можно обязать любого разработчика текстовых процессоров поддерживать формат, стандартизованый как формат для текстовых документов. Не эффективности ради, а совместимости для. С целью защиты интересов потребителя. В таких условиях авторы документов не будут жестко привязаны к конкретному процессору и в любой момент смогут его заменить. Рынку от этого будет только лучше, так как конкуренция станет более честной.
	Alexander S. Kharitonov 6 Jun 2006 10:37 AM
2 Павел: > Это на мой взгляд естественно. А как по другому? Допустим вы продаете софт, который осуществляет шифрование. Но насколько это шифрование хорошо? И наколько оно реально все шифрует. Кто гарантирует, что злобный хацкер не взломает шифр и что в программе и в алгоритме нет никаких закладок? Могут быть разные требования к надёжности криптозащиты. Сертификация должна быть опциоальной. Там, где она оправдана, её и так потребуют клиенты. Можешь ли представить, чтобы человек, выбирающий софт для банка, рискнул использовать несертифицированный продукт? Сертификат - удобная бумажка для того, чтобы прикрыть свою задницу в случае чужой ошибки. С другой стороны, если говорить о выборе программы для шифрования для личных целей, правильнее выбирать в зависимости от собственной оценки надёжности, здесь сертификация в спецслужбах - это скорее минус, поскольку наводит на мысль о возможных закладках.
	Shamlo 6 Jun 2006 12:11 PM
> Alexander S. Kharitonov: > Сертификация должна быть опциоальной. Там, где она оправдана, > её и так потребуют клиенты. Можешь ли представить, чтобы > человек, выбирающий софт для банка, рискнул использовать > несертифицированный продукт? Сертификат - удобная бумажка для > того, чтобы прикрыть свою задницу в случае чужой ошибки. А вот и нет. Конечно, желание прикрыть свою задницу уже в достаточной степени мотивирует отвественного за выбор сотрудника на покупку сертифицированного софта. Однако, серьезных людей обычно не устраивают рассказы о том, что и кого мотивирует. Им хочется четких гарантий, в случае нарушения которых кто-то обязательно будет нести полную ответственность. Допустим, сертификация криптософта необязательна. Сотрудник банка внедряет в своем банке какой-то "паленый" софт. Клиенты банка, разумеется, к этому процессу отношения не имеют и никак его не контролируют. Затем в результате эксплуатации этого софта у одного из клиентов со счета пропадает 10 миллионов долларов. Кто виноват? Понятно, что сотрудник банка, внедривший такой софт. Какова мера его ответственности? Понятно, что 10 миллионов. Как ее взыскать? Вычитать из зарплаты по 20% ежемесячно? А если его уволили? А если он уже в уехал в США? А если он вообще умер? Если же мы хотим повесить ответственность на сам банк, то внедрение "левого" софта должно считаться нарушением. Чтобы так было, сертификация должна являться обязательным условием.
	Угрюмый сангвиник 6 Jun 2006 5:01 PM
>>Если же мы хотим повесить ответственность на сам банк, то >>внедрение "левого" софта должно считаться нарушением. Чтобы >>так было, сертификация должна являться обязательным условием. Три вопроса: 1. Гарантирует ли наличие сертификата качество сертифицированного продукта по сравнению с несертифицированным? 2. Означает ли отсутствие сертификата недоброкачественность несертифицированного продукта по сравнению с несертифицированным? 3. Кто несет ответственность за недоброкачественность сертифицированных продуктов, если сертификацию проводит окологосударственная организация? Точнее так, вы слышали о случаях ответственности уполномоченных российских организаций за сертификацию недоброкачественных программных продуктов? Или вы скажете, что таких случаев нет?...
	Угрюмый сангвиник 6 Jun 2006 5:02 PM
Опечатался в п.2 - читать "несертифицированного по сравнению с сертифицированным"
	Shamlo 6 Jun 2006 5:58 PM
> Угрюмый сангвиник: > 1. Гарантирует ли наличие сертификата качество > сертифицированного продукта по сравнению с несертифицированным? Нет. Но наличие сертификата продлевает цепочку ответственности. Если он будет обязательным, то при его отсутствии крайним оказывается банк, а в случае наличия, банк ничего не нарушает. > 2. Означает ли отсутствие сертификата недоброкачественность > несертифицированного продукта по сравнению с сертифицированным? Нет. Отсутствие сертификата вообще ничего не означает. > Точнее так, вы слышали о случаях ответственности > уполномоченных российских организаций за сертификацию > недоброкачественных программных продуктов? Не слышал. Но не слышал и о том, что они уходят от ответственности.
	Alexander S. Kharitonov 6 Jun 2006 8:26 PM
2 Shamlo: > Нет. Но наличие сертификата продлевает цепочку ответственности. Если он будет обязательным, то при его отсутствии крайним оказывается банк, а в случае наличия, банк ничего не нарушает. Если со счёта клиента банка пропали деньги, перед клиентом в любом случае должен отвечать банк. Связи с сертификацией здесь нет. Если ошибка возникла по причине того, что сотрудники банка пользовались несертифицированными степлерами (и какие-то бумаги потерялись), то что, банк не будет нести ответственности перед клиентом и переведёт стрелки на сотрудника? И во избежание этого нужно сертифицировать канцелярские принадлежности? Руководство банка заинтересовано в надёжной работе, работники банка заинтересованы в том, чтобы это желание руководства выполнялось. А в сертификации и лицензировании в первую очередь заинтересованы чиновники.
	Alexander S. Kharitonov 6 Jun 2006 8:29 PM
2 Shamlo: > Не слышал. Но не слышал и о том, что они уходят от ответственности. Поступим так - найди законодательные нормы, устанавливающие ответственность ведомства за деятельность фирм, которым оно выдало лицензии.
	Shamlo 6 Jun 2006 10:13 PM
> Alexander S. Kharitonov: > Если со счёта клиента банка пропали деньги, перед клиентом в > любом случае должен отвечать банк. Связи с сертификацией > здесь нет. Есть и самая прямая. Перед клиентом, конечно, ответственность в любом случае несет банк. Он так или иначе вернет ему деньги, если ему не удастся доказать то, что это сам клиент куда-то их перевел. А вот дальше все зависит от сертификации. Если сертификата на ПО у него нет, то банк оказывается крайним в цепочке и на этом как бы конец. Если же ПО сертифицировано и можно как-то доказать то, что деньги пропали именно из-за нарушений в работе этого ПО, то появляется любопытная перспектива. Банк может подать кассационный иск на того, кто своим сертификатом удостоверил надежность ПО. И в тексте этого иска он сможет выразить как все свои материальные претензии так и всю глубину своего возмущения.
	Shamlo 6 Jun 2006 10:31 PM
> Alexander S. Kharitonov: > Поступим так - найди законодательные нормы, устанавливающие > ответственность ведомства за деятельность фирм, которым оно > выдало лицензии. А такие есть?
	Павел 7 Jun 2006 11:41 AM
2 Alexander S. Kharitonov: >Сертификация должна быть опциоальной. А она и так опциональная. Но если ты ее не прошел, то не говори, что твой продукт осуществляет криптозащиту. В современном мире, где потребительские свойства товара определяются рекламой, а не свойствами самого товара это более чем оправдано на мой взгляд. Также на рынке нельзя продавать несертифицированные товары питания. Да почти ничего несертифицированного продавать нельзя. В некоторых случаях это обусловлено "А в сертификации и лицензировании в первую очередь заинтересованы чиновники.", в некоторх более чем оправдано.
	Alexander S. Kharitonov 8 Jun 2006 5:44 PM
2 Павел: > Также на рынке нельзя продавать несертифицированные товары питания. Продукты питания - это всё-таки другое. От их качества может зависеть здоровье и даже жизнь человека, при этом они приобретаются в большом объёме, множеством партий, и из разных источников. Можно ли представить, чтобы перед тем, как купить пирожок на улице человек зашёл на форум, спросил совета у знающих людей - можно ли доверять этим конкретным пирожкам?.. А если выбирается программа для шифрования, то возможно изучить вопрос и сделать обоснованный выбор.
	xxx2 - nxxo5email.ua 12 Oct 2006 12:02 AM
В Microsoft Office поддержки XML форматов нет, поэтому сравнивать действительно не с чем :)). К тому же созданный m$ проприетарный формат значительно уступает повозможностям OAZIS Open Doc, cтавший признанным стандартом офисных документов. Oн уже сейчас поддерживается в OpenOffice (http://openoffice.ru/) (http://www.i-rs.ru/download) Будущее все равно за XML форматами. Они имеют массу преимуществ: легче обрабатываются, могут с легкостью применятся в сетевых приложениях, расширяемы. Закрытые бинарные форматы документов типаDOC,XLS,PPT по - видимому ждет смерть лет этак через 4-5.
	Alex 24 Jan 2007 1:52 PM
qalay