LINUX.ORG.RU

Microsoft идет навстречу

 


0

0

21-го февраля 2008 Стив Балмер выступил с заявлением, объявив о ряде шагов, которые намерена предпринять корпорация для улучшения открытости своих продуктов. Действия направлены на обеспечение эффективного взаимодействия, а также на предоставление широкого выбора для разработчиков, партнеров, клиентов а также конкурентов компании.

В частности, отныне Microsoft намерена:

  • гарантировать открытость взаимодействия с продуктами третьих сторон;
  • содействовать переносимости даных;
  • усиливать поддержку промышленных стандартов;
  • поощрять открытость сотрудничества с клиентами а также сообществами opensource.
Список продуктов, к которым применяется оглашённая политика, включает: Windows Vista (включая .NET Framework), Windows Server 2008, SQL Server 2008, Office 2007, Exchange Server 2007, and Office SharePoint Server 2007, а также будущие версии названых продуктов.

В качестве непосредственных первых шагов корпорация намерена:
  • начиная с сегодняшнего дня опубликовать на ресурсе MSDN более 30 тыс. страниц документации по протоколу клиент-серверного взаимодействия Windows, которая раньше являлась коммерческой тайной и предоставлялась только по специальной лицензии через Microsoft Work Group Server Protocol Program (WSPP).
  • на вебсайте Microsoft собирается указывать, какие из протоколов защищены патентами корпорации и введет их лицензирование под разумными недискриминирующими условиями с низкой оплатой.
  • корпорация согласна отказаться от судебного преследования разработчиков, занимающихся разработкой и некоммерческим использованием продуктов с открытым исходным кодом, в которых реализованны указанные протоколы. Более того, эти разработчики получат бесплатный доступ к документации. Компании, которые намерены заниматься коммерческим распространением подобного ПО, имеют возможность получить лицензию на использование патентов Microsoft.

>>> И еще много всякого

★★★★★

Проверено: svu ()

Ответ на: комментарий от dikiy

>Ты волен использовать только то, что считаешь нужным.

то есть, я таки могу выкинуть нахрен идиотские XML-тэги? только это уже не XML будет…

>Там багов больше 4000 есть и было. И находят до сих пор.

O_o

>tex имеет другую область применения. Это система верстки, а не автоматизированный аппарат.

TeX ещё и формат представления. а я вообще про Literate Programming говорил.

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

пожалуйста, дай мне C-код, который смещает указатель на символ назад. для UTF-8. а я тебе для любого формата, где размер символа фиксирован и кратен байту. у кого проще и быстрее будет?

также: скажи, пожалуйста, сколько мне выделить памяти для строки из 15 символов? нет-нет, не надо «с запасом». мне надо ровно 15 символов. чтобы «без запаса».

кстати, C-код подсчёта длины строки (пусть, к примеру, 0-terminated) для UTF-8 тоже покажи. а я — для фиксированного размера.

пардон, я лично не считаю решение из костылей «удачным». оно идиотское и усложняющее жизнь. UTF-8 — это именно костыль, появившийся в результате нежелания ломать инет-протоколы. однако для IPv4 такого костыля, почему-то, не сделали — сделали IPv6. и ничего — перейдут. не вижу, отчего не утопить костыль UTF, и не перейти на UCS.

>ужостьнах. Если сюзя летает по сравнению…..

ну, это в слаке лечится, конечно. путём взятия tukaani pkgtools, которые 100% compatible, но шибко шустрее.

к тому же intallpkg шустрый. %-)

>Если Иксы ставишь, то он в них и бутается сразу. Иначе нафига они нужны?

я хочу опцию, которая мне даст это безобразие оторвать. для справедливости — в слаке всё ровно наоборот, и тоже без опции, но я лично считаю идеологически неверным бутятся в иксы. я пожил с этим ровно 3 дня. «ужас и моральный террор» (ц)

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

>пожалуйста, дай мне C-код, который смещает указатель на символ назад. для UTF-8. а я тебе для любого формата, где размер символа фиксирован и кратен байту. у кого проще и быстрее будет?

Никто не спорит, что, если длина нефиксирована, то скорость будет чуть-чуть меньше. Но ты же не юзаешь FAT32 из-за того, что в line read/write она быстрее чем все остальные ФС?
Проигрыш в скорости у UTF8 незначителен. Зато выигрыш во все остальном.

       Набор  символов  Unicode  3.0  является  16-битным  кодом.
       Наиболее распространенная кодировка Unicode, известная как
       UCS-2,  содержит  последовательности 16-битных слов. Такие
       строки могут содержать комбинации символов (например, '\0'
       или  '/'),  которые  имеют  специальное  значение в именах
       файлов и других параметрах функций из библиотеки языка  C.
       Кроме  того,  большинство  утилит  UNIX  предназначены для
       обработки ASCII-файлов и не могут читать 16-битные символы
       без   специальной  модификации.  По  этим  причинам  UCS-2
       является неподходящей кодировкой  имен  файлов,  текстовых
       файлов,  переменных окружения Unicode и т.д.  Стандарт ISO
       10646 Universal Character  Set  (UCS)  является  31-битным
       кодом,   а   используемая   для   него   кодировка   UCS-4
       (последовательность   32-битных   слов)   имеет   те    же
       недостатки, что и описанные выше.  Кодировка Unicode и UCS
       под названием UTF-8 лишена  этих  недостатков  и  является
       общим   методом   использования  Unicode  в  Unix-подобных
       операционных системах.

>TeX ещё и формат представления. а я вообще про Literate Programming говорил.

А как это на русском?

>также: скажи, пожалуйста, сколько мне выделить памяти для строки из 15 символов? нет-нет, не надо «с запасом». мне надо ровно 15 символов. чтобы «без запаса».

15*4 байт. Вот. Без запаса. Максимально возможный теоретический размер строки из 15 символов (включая всякие китайские и т.п.).

>кстати, C-код подсчёта длины строки (пусть, к примеру, 0-terminated) для UTF-8 тоже покажи. а я — для фиксированного размера.

Давай я тебе покажу код для чтения файла из FAT12,  ты мне для файла из ext2?

>пардон, я лично не считаю решение из костылей «удачным». оно идиотское и усложняющее жизнь. UTF-8 — это именно костыль, появившийся в результате нежелания ломать инет-протоколы. однако для IPv4 такого костыля, почему-то, не сделали — сделали IPv6. и ничего — перейдут. не вижу, отчего не утопить костыль UTF, и не перейти на UCS.

Читай википедию. Там все написано. интернет протоколы тут ни при чем.

>я хочу опцию, которая мне даст это безобразие оторвать. для справедливости — в слаке всё ровно наоборот, и тоже без опции, но я лично считаю идеологически неверным бутятся в иксы. я пожил с этим ровно 3 дня. «ужас и моральный террор» (ц)

Есть там все опции. Отрывай что хошь.

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

>Ты так и не привел аргументов того, что XML гавно. http://www.linux.org.ru/jump-message.jsp?msgid=2420602&cid=2422662

То, что его пихают куда не лень, это не значит, что оно гавно.

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

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

>То, что его пихают куда не лень, это не значит, что оно гавно.

Этой ссылкой я хотел показать один существенный недостаток xml, проистекающий как-раз из его многословности, - медленность. А сетевые протоколы - далеко не то место, куда следует пихать форматы, требующие длительного парсинга, не находишь?

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

>Кроме того, большинство утилит UNIX предназначены для обработки ASCII-файлов и не могут читать 16-битные символы без специальной модификации.

после этого ты мне будешь доказывать, что UTF — не костыль? благодарю за то, что мне не пришлось гуглить: ты отлично справился за меня. сам сказал, сам себя опроверг, сам доказал опровержение.

«итого: слушали. постановили: костыль, в ту же топку, что и EBCDIC». к сожалению, нормальную поддержку UCS везде (от ядра до софта) я один ниасилю сделать. а ты и прочие дезориентированные (это не оскорбление %-) товарищи настолько довольны тем, что вожделенные нелатинские буковки наконец рисуются, что просто потерялись где-то в этой эйфории. %-(

>А как это на русском?

хер его знает. на языке оригинала — вот: http://en.wikipedia.org/wiki/Literate_programming

>Максимально возможный теоретический размер строки из 15 символов

мне не надо «максимально возможный». это как раз «с запасом». мне надо, чтобы ровно 15 символов влезло. и *ровно* на 15 символов выделить памяти. безо всяких «максимально возможный». а то в твои 15*4 от 15 до 60 символов помещается. это, прадон, «с офигенным запасом».

что я пытаюсь сказать — это что если размеры структуры со строкой зависят от того, что содержится в этой строке, то подобное называется кратко и ёмко: «идиотизм». круче будет только если размер байта станет плавающим.

>Давай я тебе покажу код для чтения файла из FAT12, ты мне для файла из ext2?

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

>Читай википедию. Там все написано. интернет протоколы тут ни при чем.

«By early 1992 a search was on for a good byte-stream encoding of multi-byte character sets.»

понимать так, что искали от нечего делать, а инет-протоколы вовсе и никаким боком?

впрочем, извиняюсь, я, конечно, фигню сказал. появился он вовсе не от того, сказанное мной — лишь одна из многих причин, держащих сей костыль на плаву (главная, конечно, что д…ерево не тонет %-).

>Есть там все опции. Отрывай что хошь.

значит, я не нашёл. тогда я ещё попрошу опцию, которая отрывает нафиг зависимости и переводит пакеты в .tgz. %-)

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

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

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

>пожалуйста, дай мне C-код, который смещает указатель на символ назад. для UTF-8. а я тебе для любого формата, где размер символа фиксирован и кратен байту. у кого проще и быстрее будет?

Си-быдлокодер? Рекоммендую WIN-1251, там русские символы идут в алфавитном порядке, и заглавные буквы от строчных всегда отстоят на константное значение кода. Очень эффективно.

>кстати, C-код подсчёта длины строки (пусть, к примеру, 0-terminated) для UTF-8 тоже покажи. а я — для фиксированного размера.

Все равно сложность этой операции будет O(N), в то время как на всех других языках она будет O(1).

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

>Этой ссылкой я хотел показать один существенный недостаток xml, проистекающий как-раз из его многословности, - медленность. А сетевые протоколы - далеко не то место, куда следует пихать форматы, требующие длительного парсинга, не находишь?

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

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

>после этого ты мне будешь доказывать, что UTF — не костыль? благодарю за то, что мне не пришлось гуглить: ты отлично справился за меня. сам сказал, сам себя опроверг, сам доказал опровержение.

конечно нет. Это не костыль. Это расширение.

>«итого: слушали. постановили: костыль, в ту же топку, что и EBCDIC». к сожалению, нормальную поддержку UCS везде (от ядра до софта) я один ниасилю сделать. а ты и прочие дезориентированные (это не оскорбление %-) товарищи настолько довольны тем, что вожделенные нелатинские буковки наконец рисуются, что просто потерялись где-то в этой эйфории. %-(

И никто этого не осилит. Никаких преимуществ у UCS, кроме его фиксированной длины, нет. Остельное только недостатки.

>мне не надо «максимально возможный». это как раз «с запасом». мне надо, чтобы ровно 15 символов влезло. и *ровно* на 15 символов выделить памяти. безо всяких «максимально возможный». а то в твои 15*4 от 15 до 60 символов помещается. это, прадон, «с офигенным запасом».

Это не с запасом. Кто тебе сказал, что символы - это только кириллица и латиница? А китайские буквы или иврит и т.п.? Это не с запасом. Это именно ровно столько, сколько может понадобится.

>а давай ты не будешь подменять предмет дискуссии? что-то я не помню, где мы прекратили обсуждать кодировки и работу со строками, да перешли к FS. только в этом твоём сообщении, где ты понял, что на горизонте замаячила лажа, и попытался увильнуть.

Да куда мне увильнуть. От такого дурацкого утверждения, что UTF не нужен увиливать не надо. Я тебе лишь привел параллель.

>впрочем, извиняюсь, я, конечно, фигню сказал. появился он вовсе не от того, сказанное мной — лишь одна из многих причин, держащих сей костыль на плаву (главная, конечно, что д…ерево не тонет %-).

Каким образом это костыль ты так и не сказал. То что ASCII поддерживается изначально - это не костыль, а достоинство. Следуя тебе и koi8-r костыль. Так как там без старшего 8-го бита сохраняется "фонетическая" читабельность русских символов.

>значит, я не нашёл. тогда я ещё попрошу опцию, которая отрывает нафиг зависимости и переводит пакеты в .tgz

Зависимости - это тоже костыль?

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

>конечно нет. Это не костыль. Это расширение.

ага. костыльное.

>И никто этого не осилит. Никаких преимуществ у UCS, кроме его фиксированной длины, нет. Остельное только недостатки.

пожалуйста, опиши эти «недостатки». про то, что «переписывать софт» не надо, это понятно. его и для UTF надо переписывать.

>Это не с запасом.

это с запасом. «не с запасом» — когда все байты используются. если остались «лишние» — это запас.

>Я тебе лишь привел параллель.

некорректную. сравнивать круглое с зелёным — некорректно, даже если это два круга.

>Каким образом это костыль ты так и не сказал.

сказал. тем, что пытались сохранить никому не нужную совместимость с ASCII. почти любое решение, в котором пытаются сохранить совместимость со всякой архаикой, является костылём. by design.

>Следуя тебе и koi8-r костыль.

натурально. потому что UCS надо. но увы… кстати, 1251 — намного более вменяемая кодировка.

>Зависимости — это тоже костыль?

нет. зависимости — это то, что лично мне нафиг не надо и раздражает.

>длительный парсинг нужен, если xml документ сложный. Иначе все происзодит достаточно быстро.

а не проще было изначально взять формат, который проще парзится? лучше — бинарный. и little-endian, как наиболее распространённое на десктопах.

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

>это то, что лично мне нафиг не надо и раздражает.

А еще его наверное раздражает крик пяьного японца на левом склоне горы фужзияма, ибо он ему на фиг не нужен.

Психотерапевт поможет

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

>длительный парсинг нужен, если xml документ сложный. Иначе все происзодит достаточно быстро.

Вообще-то xml и придумали для документов со сложной структорой. А в простых он нафиг не нужен, там вполне сгодится plain text. Тем более он не нужен в сетевых протоколах, где клиент посылает пакет серверу, тот тратит время на его парсинг, затем посылает ответ клиенту, тот тоже его некоторое время парсит, затем посылает ответ серверу - и так несколько раз.

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

>В слаке нет => костыль

iRunix, а тебя какие-то комплексы, связанные со слакой? Здесь вообще кто-то говорит про неё (кроме тебя, естесственно)? Может тебе стоит обратиться к психиатру? ;)

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

>iRunix, а тебя какие-то комплексы, связанные со слакой?

У mirage есть.

>Здесь вообще кто-то говорит про неё (кроме тебя, естесственно)?

mirage тыкает что зависимости его бесят.

>Может тебе стоит обратиться к психиатру? ;)

не стоит. Мы друг друга не поймем

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

>ага. костыльное.

в каком месте оно костыльное?

>пожалуйста, опиши эти «недостатки». про то, что «переписывать софт» не надо, это понятно. его и для UTF надо переписывать.

Даже если программа не распознаёт Юникод, то латинские буквы, арабские цифры и знаки препинания будут отображаться правильно. В случае, если латинские буквы и простейшие знаки препинания (включая пробел) занимают существенный объём текста (например, в европейских языках, включая основанные на кириллице), UTF-8 даёт выигрыш по объёму по сравнению с UTF-16.[1][2] На первый взгляд может показаться, что UTF-16 удобнее, так как в ней большинство символов кодируется ровно двумя байтами. Однако это сводится на нет необходимостью поддержки суррогатных пар, о которых часто забывают при использовании UTF-16, реализовывая лишь поддержку символов UCS-2.[1] Работа с UTF-8 может требовать немного больше процессорных ресурсов, так как UTF-8 является кодировкой UTF-16, а не кодировкой непосредственно Уникода

Вот тебе с википедии.

Да и один из больших недостаток - это фиксированный размер.

>некорректную. сравнивать круглое с зелёным — некорректно, даже если это два круга.

Вполне корректную. В том случае тоже жертвуют скоростью во благо расширяемости и удобства.

>сказал. тем, что пытались сохранить никому не нужную совместимость с ASCII. почти любое решение, в котором пытаются сохранить совместимость со всякой архаикой, является костылём. by design.

Почему она никому не нужная? Это не просто совместимость с ASCII. Это совместимость с идеей однобайтной кодировки. Ведь есть же и embedded системы и т.п. ASCII - не архаичность, а широко используемая весчъ.

>нет. зависимости — это то, что лично мне нафиг не надо и раздражает.

А. ну ясно. Конечно же. Руками качать все нужные либы и т.п. намного удобнее...

>а не проще было изначально взять формат, который проще парзится? лучше — бинарный. и little-endian, как наиболее распространённое на десктопах.

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

Нужен структурированный формат передачи. В каком месте набор байтов простых является структурированным? Ведь XMPP - это не обычная аська(tm).

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

>Вообще-то xml и придумали для документов со сложной структорой. А в простых он нафиг не нужен, там вполне сгодится plain text. Тем более он не нужен в сетевых протоколах, где клиент посылает пакет серверу, тот тратит время на его парсинг, затем посылает ответ клиенту, тот тоже его некоторое время парсит, затем посылает ответ серверу - и так несколько раз.

времени на парсинг тратится таки очень мало. Ты, видать, начитался лоровских аналитиков. парсить и так и так надо. Это ж не плэйнтекстом обмениваться... Вот и взяли xml. Как один из наиболее разработанных форматов. С видов на будущее.

PS Ты XEP-... почитай. Потом расскажешь мне, как ты это plin text'ом собрался реализовывать.

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

>в каком месте оно костыльное?

я заебался повторять одно и то же.

>Даже если программа не распознаёт Юникод, то

её надо отправить на переработку.

>В том случае тоже жертвуют скоростью во благо расширяемости и удобства.

хихик.

>Это совместимость с идеей однобайтной кодировки. Ведь есть же и embedded системы и т.п.

предлагаю всё-таки вернуть EBCDIC. она ещё экономней. и лишний бит у байта отрезать.

ну право же, экономить на тексте даже в embedded — это глупость. если там много текста — то можно и памяти добавить. а если памяти с гулькин хуй, то там обычно и текст нахер не впёрся.

>ASCII — не архаичность, а широко используемая весчъ.

широко используемая архаичность.

>Руками качать все нужные либы и т.п. намного удобнее…

удобнее. и cron не потащит за собой postfix.

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

прикинь — да.

>В каком месте набор байтов простых является структурированным?

в том же, в каком и XML, коя не более, чем набор простых байтов. идеея бинарного расширяемого протокола, по-твоему, настолько сложна?

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

>её надо отправить на переработку.

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

>хихик.

Смех без причины признак...

>предлагаю всё-таки вернуть EBCDIC. она ещё экономней. и лишний бит у байта отрезать. ну право же, экономить на тексте даже в embedded — это глупость. если там много текста — то можно и памяти добавить. а если памяти с гулькин хуй, то там обычно и текст нахер не впёрся.

Посмотрел что такое EBCDIC.... "Было 6 разных несовместимых версий..." И кому оно надо?

А в embedded дело не в экономии, а в простоте реализации.

>в том же, в каком и XML, коя не более, чем набор простых байтов. идеея бинарного расширяемого протокола, по-твоему, настолько сложна?

именно. Она будет не проще, чем xml в конечном счете. Да и зачем изобретать ваелосипед?

>удобнее. и cron не потащит за собой postfix.

Ну потащил один раз. так что, теперь ты в отместку сам зависимости вычисляешь и со злобным выражением лица качаешь по 10 пакетов руками?

Кто-то тут про M$-way говорил.... Мне кажется, что у тебя Патрик-way.

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

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

и не надо. «заморациваться» — это как раз к UTF. для UCS — обычная работа с char. который просто стал чуть больше, что в принципе не важно при правильном написании софта.

>А в embedded дело не в экономии, а в простоте реализации.

это UTF-то проще UCS? ржу аки лошадко.

>Она будет не проще, чем xml в конечном счете.

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

>теперь ты в отместку сам зависимости вычисляешь и со злобным выражением лица качаешь по 10 пакетов руками?

не в «отместку», а потому что мне так удобней. вообще-то swaret/slapt-get зависимости умеют, и на slacky.eu их (зависимости) прописывают.

но я вообще предпочитаю (к монстрам это не относится %-) собирать ручками с оптимизацией под мою технику. ибо pIII/600, и разница между mplayer «искаропки» и собраным лично, например, весьма заметна. также имею привычку поселять софт в доме, каждого в свой каталог. ибо мне так удобней, да.

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

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

Ага, C:/program files/$softname, летали, знаем :)

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

>и не надо. «заморациваться» — это как раз к UTF. для UCS — обычная работа с char. который просто стал чуть больше, что в принципе не важно при правильном написании софта.

А зачем мне UCS, котоый "чуть больше", если есть ASCII, который "как раз"?

>это UTF-то проще UCS? ржу аки лошадко.

Это ASCII проще.

>зато офигенно экономней и шустрее. зачем использовать тормозную фиготень, если можно нормальную шуструю вещь?

таки не офигенно экономней. А шустрота в данном случае не решает. Намного больше времени тартиться на передачу пакета, чем на его обработку.

>не в «отместку», а потому что мне так удобней. вообще-то swaret/slapt-get зависимости умеют, и на slacky.eu их (зависимости) прописывают.

Ну, если удобней, значит гут. А когда Патрик зависимости железно прошьет в дистр, ты их отрывать небось будешь?

>но я вообще предпочитаю (к монстрам это не относится %-) собирать ручками с оптимизацией под мою технику. ибо pIII/600, и разница между mplayer «искаропки» и собраным лично, например, весьма заметна. также имею привычку поселять софт в доме, каждого в свой каталог. ибо мне так удобней, да.

Возможно.

Ну а софт поселять в хомяке ты и с rpm-based можешь легко.

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

> mplayer «искаропки» и собраным лично, например, весьма заметна. также имею привычку поселять софт в доме, каждого в свой каталог. ибо мне так удобней, да.

Вдогонку:

софт в хомяке (и, как следствие, хомяк без noexec в fstab) открытая дыра для вирусов и червей (SELinux, как я понимаю, у тебя не стоит).

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

>в слаке нет SElinux. И потом он не сказал что в хомяке. У меня тоже в /opt/$softname не одна софтина собрана :)))

Мда. Без SELinux ставить софт на раздел, на который юзер из под которого работаешь имеет право на запись это ппц.

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

>Ага, C:/program files/$softname, летали, знаем :)

Почему-то я уверен, что если бы кто-то десяток страниц назад начал ругать эту схему, ты обязательно начал бы с ним спорить.. ;)

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

>Ага, C:/program files/$softname, летали, знаем :)

Это скорее C:/Documents ans settings/$softname

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

>Почему-то я уверен, что если бы кто-то десяток страниц назад начал ругать эту схему, ты обязательно начал бы с ним спорить.. ;)

Спорить то тут не о чем. Безумный шлаковод крошит батон на современный индустриальный стандарт представления текстовых данных и кроме того не знает про locale.h и прочих небыдлокодерских приемов работы со строками. Кроме того, он желает чтобы FOSS community перелопатило весь современный массив Си-кода для того чтобы везде поменять char* на wchar_t*. И чтобы под Шлакой это заработало.

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

>А зачем мне UCS, котоый «чуть больше», если есть ASCII, который «как раз»?

потому что в ASCII русских буковок нет.

>Это ASCII проще.

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

>Намного больше времени тартиться на передачу пакета, чем на его обработку.

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

>А когда Патрик зависимости железно прошьет в дистр

пока такой тенденции не намечается. и не наметится, я полагаю. если Патрик таки сойдёт с ума — соберу себе свой slackware-based.

>софт поселять в хомяке ты и с rpm-based можешь легко.

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

>софт в хомяке (и, как следствие, хомяк без noexec в fstab) открытая дыра для вирусов и червей (SELinux, как я понимаю, у тебя не стоит).

SELinux не стоит. также я не ставлю ни вирусов, ни червей. пока живой.

кстати: а можно ссылок на вирусов да червей? интересно же.

а, да: gcc тоже штука опасная, если так рассуждать.

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

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

>техника у меня используется только мной.

Конечно, кто же еще в здравом уме такой техникой пользоваться? Все уже с 600 целика обновились давно.

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

>потому что в ASCII русских буковок нет.

и что?

>покажи мне существенную разницу между ASCII и UCS. кроме того, что UCS не ограничен анлийским языком и цифирками с кусочком пунктуации.

UCS - это ни рыба ни мясо. Это то же ASCII по большому счету, только двухбайтное. С ASCII не совместимо, а как современная кодировка не подходит.

А использовать вместо ASCII не нужно, так как есть ASCII, который однобайтный.

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

И кто сказал, что меньше? 1. Управляющие заголовки в любом случае нужны. 2. При передача с помощью SSL или еще каких-то методов шифрации эта незначительная разница и так исчезает. 3. С xml просто напросто удобнее работать и в последствии. Да хоть логи обрабатывать.

>пока такой тенденции не намечается. и не наметится, я полагаю. если Патрик таки сойдёт с ума — соберу себе свой slackware-based.

Ну-ну. Можешь уже начинать.

>я в курсе. ровно тем же способом, каким я это делаю сейчас — собирать руками. а в каком формате архива идут исходники — оно не важно.

ты показал всего лишь свое незнание предмета. никаких собирать руками не надо. я могу установить rpm'ку куда угодно без всяких пересборок. И пример уже приводил.

>SELinux не стоит. также я не ставлю ни вирусов, ни червей. пока живой. Они тебя спрашивать не будут.

>кстати: а можно ссылок на вирусов да червей? интересно же. поставь rkhunter. там есть база всяких бэкдоров и т.п.

>а, да: gcc тоже штука опасная, если так рассуждать.

ни в коей мере.

Браузер у тебя падал? Падал. Это значит, где-то segfault мог быть вызван кодом на странице => получаешь полное управление компом при желании.... Я, надеюсь, ясно выразился?

Как говорится: надежда умирает последней. Тешься дальше, что под линь не так много вирусни.

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

новость не читал. все камменты одобряю.

Microsoft идет навстречу стенке.

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

>P.S. Под Linux какое 64-битное приложение (кроме Wine) не работает, не подскажете? ;-) >R_Valery (*) (23.02.2008 3:02:41) Плагин к браузерам (флэшки) ,многие 32 приложения (хотя конечно их не тестировали на 64 бита ) в режиме совместимости (acrobat ,многие игрушки под библиотеку sdl ,отладчики и трассировщики -тут нечего удивительного нет )

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

>и что?

а, ты их маркером рисуешь, а живёшь в омерике? лично мне русские буковки нужны --> ASCII фтопку.

>UCS — это ни рыба ни мясо. Это то же ASCII по большому счету, только двухбайтное.

тебе подвезли цистерну метана и её теперь некуда девать?

>как современная кодировка не подходит.

обосновать?

>А использовать вместо ASCII не нужно, так как есть ASCII, который однобайтный.

привет, омериго! (кстати: а ты в курсе, что ASCII — семибитный вообще?)

>И кто сказал, что меньше? 1. Управляющие заголовки в любом случае нужны.

тебе не ясно, как оные могут быть меньше, чем тэги XML?

>2. При передача с помощью SSL или еще каких-то методов шифрации эта незначительная разница и так исчезает.

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

>3. С xml просто напросто удобнее работать и в последствии.

как было неудобно изначально, так и дальше неудобно.

>Да хоть логи обрабатывать.

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

>Ну-ну. Можешь уже начинать.

у тебя был сеанс связи с Патириком через libastralconnect и он тебе дал эксклюзивные данные? я вот в slackware-current не наблюдаю никаких зависимостей.

>я могу установить rpm'ку куда угодно без всяких пересборок.

вторая цистерна метана? ты не в курсе, что многие софтины хардкодят пути к файлам данных и конфигов на этапе configure, например? толку с того, что ты развернул бинарный rpm в /1/2/3, если данные оно ищет в /usr/share? или предлагаешь потом танцевать, создавая линки? так что незнание предмета показал именно ты.

>Я, надеюсь, ясно выразился?

в данном случае я вполне доверяю community, которая служит гарантом непропускания «злого» кода в софт. и Opera Software я тоже доверяю, да.

>Тешься дальше, что под линь не так много вирусни.

так тешусь. более того — даже не подхватывал пока. более того — на страшном оффтопике 6 лет отлично жил без антивируса и под админом — а вирусни всё равно не подхватывал. может, проблемы с вирусами не в инструментах, а в голове?

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

>а, ты их маркером рисуешь, а живёшь в омерике? лично мне русские буковки нужны --> ASCII фтопку.

латиница - стандарт изначально. Кириллица - нет.

>>UCS — это ни рыба ни мясо. Это то же ASCII по большому счету, только двухбайтное. >тебе подвезли цистерну метана и её теперь некуда девать?

У тебя какие-то конкретые возражения есть?

>>UCS-2 как современная кодировка не подходит. обосновать?

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

>тебе не ясно, как оные могут быть меньше, чем тэги XML?

См. остальные пункты.

>да? разве уже применяются методы шифрования, которые добавляют дофига избыточности? TSL Handshake — он один раз происходит. дальше тупо поток шифрованый.

-rw-r--r-- 1 dikiy dikiy 98 Мар 16 00:49 test.txt -rw-r--r-- 1 dikiy dikiy 443 Мар 16 00:50 test.txt.gpg -rw-r--r-- 1 dikiy dikiy 479 Мар 16 00:51 test.txt.gpg.gz

[dikiy@localhost tmp]$ cat test.txt Пpощаюсь всеми тpемя головами. _Гоpыныч_ AKA _Пеpнатый Змей._

... а я сейчас слушаю магнитофон

[dikiy@localhost tmp]$

вот. Вопросы есть? За своей цистерной смотри.

выход шифровальщика ничем не отличается от /dev/random

>как было неудобно изначально, так и дальше неудобно.

Если тебе приятно так думать, тогда думай. А остальные будут использовать.

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

Полученный пакет в логах имеет вид:

<msg nick="" in="1" from="linuxforum@conference.jabber.ru" time="3 16:23:19" >Juliette has set the subject to: C богом общайтесь в привате || Сегодня за бота злой Warderer! Знает только две команды &quot;kick&quot; и &quot;ban&quot; || а погоды не знает </msg>

А сам лог имеет заголовок XML. В результате удобно перегонять в любой вид.

>вторая цистерна метана? ты не в курсе, что многие софтины хардкодят пути к файлам данных и конфигов на этапе configure, например? толку с того, что ты развернул бинарный rpm в /1/2/3, если данные оно ищет в /usr/share? или предлагаешь потом танцевать, создавая линки? так что незнание предмета показал именно ты.

Гы. ну так если на то пошло. Так тогда в любой системе пересобирать придется. Ну а пересобрать и src.rpm все проще. Автоматом по зависимотям пройдет и все. Это тебе не с инета качать руками пакеты и собирать каждый руками. И т.д. Гиморру туча. Знаем. Делали иногда.

>в данном случае я вполне доверяю community, которая служит гарантом непропускания «злого» кода в софт. и Opera Software я тоже доверяю, да.

Ты не понял нифига. Программу можно уронить в segfault => с 95% вероятностью программу можно заставить выполнить любой код на твоем компе. А если программа имеет права на запись в твой хомяк, то будут зараженными все твои бинари в хомяке.

>так тешусь. более того — даже не подхватывал пока. более того — на страшном оффтопике 6 лет отлично жил без антивируса и под админом — а вирусни всё равно не подхватывал. может, проблемы с вирусами не в инструментах, а в голове?

Ага. И оффтопик в инет выходил каждый день. Ну давай. Какие еще сказки знаешь?

Наверное потому и не подхватывал, что антивируса не было:) Вирусы о себе сами редко сообщают.

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

>латиница — стандарт изначально. Кириллица — нет.

привед опять, омериго!

>У тебя какие-то конкретые возражения есть?

нет, у меня претензии к «Это то же ASCII по большому счету».

>Она мало того, что фиксированного размера, так еще и двух-байтная только

ты сам начал писать именно об UCS-2. я размер не указывал.

>См. остальные пункты.

посмотрел. не убедительно. логи, например, всё равно надо преобразовывать тулзовиной (ну нафига их все читать? в пень такое не надо, надо обычно оттуда выдёргивать что-то). опять же — логи можно хоть азбукой морзе писать — благо, назад их читать не приходится. я вёл речь про протокол обмена, где XML ни в хер не впёрся.

>вот. Вопросы есть? За своей цистерной смотри. выход шифровальщика ничем не отличается от /dev/random

да. вопрос есть: ты разницу между «подпись» и «шифрование» вообще ощущаешь? а-ну ка, расшифруй мне gpg в исходный файл, а?

# ls -l a

-rw-r--r-- 1 XXX users 11386 2008-03-16 03:33 a

# openssl des -des -in a -out A

# ls -l A

-rw-r--r-- 1 XXX users 11408 2008-03-16 06:11 A

(cat 11 KiB не привожу, но это был javascript-исходник %-)

дополнительные байты ушли на служебную инфу, которая нужна в файле, а в потоке передаваемом — нет (и их количество не зависит от размера файла). вопросы? используемые алгоритмы криптования не увеличивают размер данных. о чём я тебе и пытался сказать — после TLS handshake (где как раз передаются ключи и прочее, один раз за сессию) дальше пофигу, шифрованый канал или нет — всё равно XML будет жирнее бинарного протокола. никто ж не открывает новую сессию каждый раз, когда надо пакет отослать.

>Полученный пакет в логах имеет вид: … А сам лог имеет заголовок XML.

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

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

>Так тогда в любой системе пересобирать придется.

перечитай мои слова. именно это я тебе и говорил — что не вижу большой разницы между тарболом и src.rpm.

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

с какого испугу? кто это ей выдал права на запись туда? далеко не всё, что лежит в /home/jack обязано принадлежать jack'у. и далеко не везде там jack может писать. да, согласен, система несколько нестандартная, но меня устраивает. исталлит-то софт jack, а потом скриптик с sudo chown аккуратно проинсталленое у jack'а отбирает. ибо.

>И оффтопик в инет выходил каждый день.

таки да.

>Какие еще сказки знаешь?

мне, вообще-то, насрать на иронию. у меня было именно так. если ты не веришь — твоё право, от этого факты никуда не денутся.

>Наверное потому и не подхватывал, что антивируса не было:)

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

>Вирусы о себе сами редко сообщают.

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

однако же лечиться не приходилось ни разу.

зыж не надо только смешивать файрвол и антивирус. файрвол стоял — Tiny Personal Firewall. который только то и умел, что отслеживать сетевую активность — никаких идиостких слежений за хуками и прочими «подозрительными действиями». а, да — ещё проверял MD5 у файлов, которые в сеть лазили. всё.

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

> латиница - стандарт изначально. Кириллица - нет.

бред сивой кабылы. в linux это только графическое отобрадение слов и ограничение колическва кнопок на клавиатуре.

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

бгджзийлфчшщъьэюя

т.е. дай людям клавиатуру на которой на 17 кнопок больше и будет тебе счастье.

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

>латиница — стандарт изначально. Кириллица — нет. привед опять, омериго!

Можешь иронизировать сколько влезет, но от этого ничего не изменится.

>ты сам начал писать именно об UCS-2. я размер не указывал.

Так ты ж сам ucs-2 как пример приводил.

>посмотрел. не убедительно. логи, например, всё равно надо преобразовывать тулзовиной (ну нафига их все читать? в пень такое не надо, надо обычно оттуда выдёргивать что-то). опять же — логи можно хоть азбукой морзе писать — благо, назад их читать не приходится. я вёл речь про протокол обмена, где XML ни в хер не впёрся.

Иногда бывает нужно распечатать лог. Или еще что-то с ним сделать. Если он в xml его запросто перегнать можно хоть в html хоть в pdf.

>дополнительные байты ушли на служебную инфу, которая нужна в файле, а в потоке передаваемом — нет (и их количество не зависит от размера файла). вопросы? используемые алгоритмы криптования не увеличивают размер данных. о чём я тебе и пытался сказать — после TLS handshake (где как раз передаются ключи и прочее, один раз за сессию) дальше пофигу, шифрованый канал или нет — всё равно XML будет жирнее бинарного протокола. никто ж не открывает новую сессию каждый раз, когда надо пакет отослать.

А теперь попробуй зашифрованный файл сжать... Если исходный xml поддается сжатию очень хорошо, то шифрованный вообще никак.

Я, в принципе, согласен, что xml больше траффика хавает (но не намного больше). Но даже это не есть препятствием или проблемой. А сам xml удобен во всех аспектах.

>да хоть голого балмера в логи пиши — при чём тут логи? между клиентами и серверами не логи ходят, а пакеты. которые целесообразно делать бинарными. лог формируй как хочешь — лог есть интимным делом софтины, и к протоколу отношения не имеет.

Можешь написать надстройку над XMPP, которая бинарными пакетами обмениваться будет :)

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

для апачевых логов нужна, видать, спец. софтина или программа на awk. А для xml лога нужны только стандартные средства.

>с какого испугу? кто это ей выдал права на запись туда? далеко не всё, что лежит в /home/jack обязано принадлежать jack'у. и далеко не везде там jack может писать. да, согласен, система несколько нестандартная, но меня устраивает. исталлит-то софт jack, а потом скриптик с sudo chown аккуратно проинсталленое у jack'а отбирает. ибо.

гы. а смысл тогда в хомяке? Не легче такой софт сразу в /usr/local/ ставить?

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

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

>зыж не надо только смешивать файрвол и антивирус. файрвол стоял — Tiny Personal Firewall. который только то и умел, что отслеживать сетевую активность — никаких идиостких слежений за хуками и прочими «подозрительными действиями». а, да — ещё проверял MD5 у файлов, которые в сеть лазили. всё.

Тут ни файрвол ни антивирус не помогут.

"Проверял MD5..... всё." Фактически делал самое важное. А ты "всё" %)

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

>Так ты ж сам ucs-2 как пример приводил.

как один из вариантов, а не как единственно возиожный.

>Иногда бывает нужно распечатать лог. Или еще что-то с ним сделать. Если он в xml его запросто перегнать можно хоть в html хоть в pdf.

адын, например, скрипт на том же perl — и получаем вожделенный xml, если так надо.

>А теперь попробуй зашифрованный файл сжать… Если исходный xml поддается сжатию очень хорошо, то шифрованный вообще никак.

как и любые шифрованые данные. потому сжимают ДО шифрования.

>А сам xml удобен во всех аспектах.

только в одном: сшибании бабла с заказчика путём упоминания трёх модных буковок.

>Можешь написать надстройку над XMPP, которая бинарными пакетами обмениваться будет :)

тогда проще сразу XMPP похерить. разницы никто не заметит. %-)

>для апачевых логов нужна, видать, спец. софтина или программа на awk. А для xml лога нужны только стандартные средства.

да? то есть, я что-то скажу, и оно магически куда-то преобразуется? или, всё же, придётся XSL ваять? и чем ваяние XSL отличается от ваяния скрипта? если только тем, что «есть в каропке» — так готовых софтин для разбора логов апача тоже немеряно.

хотя, отличается: XSL — многословное уродство, на котором чо-то сделать — лучше сразу повеситься. знаем, плавали.

>а смысл тогда в хомяке? Не легче такой софт сразу в /usr/local/ ставить?

неа. поясню. sudo backup_my_env.sh делает бэкап дома *со всем кастомным софтом* и /etc. в /usr лежит только то, что приползло из дистриба. в итоге разворачивание новой системы — это установка слаки со своими .tag-файлами (практически полная автоматика) и накатывание поверх одного тарбола. после чего я получаю систему, заточеную под себя, без утомительного пересбора всего софта, который я натыкал из исходников. это раз.

два — я раскладываю софт в ~/zoft/<programname> обычно. и симлинкую в ~/zoft/bin и ~/zoft/lib. таким макаром даже если я снесу исходник, деинсталляция софтины делается простым удалением каталога. никакие тулзы для создания пакетов не нужны, вообще полная «пакетонезависимость». для апгрейда софта — переименовал старый каталог, собрал/поставил новую версию, проверил, не сломали ли чего — и по результатам или в пол-пинка откатился, или грохнул старьё.

>Не лазил по сайтам, где такого добра дохерища.

ну так для того на плечах не кирпич, а голова. %-)

>Фактически делал самое важное. А ты «всё» %)

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

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

а, да. почему в home, а не в /usr/local. потому что когда-то я на отдельный раздел вынес именно дом, оттуда и осталась привычка. принципиально разницы нет, конечно — можно и в /usr/local. но сам, наверное, знаешь, как дурацкие привычки сильны. %-)

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

XML это универсальный язык для описания любых структур данных, если данные хоть как-то структурированы, то их можно описать в XML. Максимальная универсальность это главное достоинство XML. Также для XML созданы схемы (XSD), которые позволяют создавать различные диалекты XML (диалекты, поддиалекты, подподдиалекты и т.д.). Благодаря этому есть возможность максимально гибко изменять строгость описания любой структуры.

> неудобный ни для создания человеком (многабукаф)

ИМХО XML не должен писаться руками, только редактироваться (в редких случаях). Но даже если его надо набрать, то существует огромное количество редакторов (благодаря простоте XML), которые ускоряют всё на порядок (если для XML написана схема, то на два порядка).

> ни для чтения человеком (многабукаф)

опять же ИМХО, человек не должен читать XML. Но редакторы с подсветкой синтаксиса и другими фичами + жуткая простота XML делают эту задачу довольно простой.

> ни для создания машиной (многабукаф), ни для чтения машиной (многабукаф)

XML жмётся обычным zip-ом на ура. Так что хранение/чтение с диска, передача по сети это не проблема. Существует огромное количество парсеров, которые отлично оптимизировали за время существования XML (потому как он прост и его приняло большинство). Кроме того наличие схемы XML позволяет ускорять работу парсеров в разы.

Короче, простота, распространённость и универсальность это огромное преимущество XML перед любыми другими форматами.

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

>Короче, простота, распространённость и универсальность это огромное преимущество XML перед любыми другими форматами.

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

зыж особенно умиляет меня пассаж про ускорение чего-либо путём навешивания сверху пары гирек.

mirage
()

согласен с теми кто считает что xml - это убогая технология. Очень плохо что ее внедряют где попало без разбора. Достаточно хотя бы того что сама информация в xml, которая передается занимает дай бог 1/4 часть всего сообщения, т.е. 75% это сервисные данные, которые нужны чтобы распарсить нужные данные.

anonymous
()

>XML жмётся обычным zip-ом на ура. Так что хранение/чтение с диска, передача по сети это не проблема. Существует огромное количество парсеров, которые отлично оптимизировали за время существования XML (потому как он прост и его приняло большинство). Кроме того наличие схемы XML позволяет ускорять работу парсеров в разы.

Ты в каком ПО видел что xml передавали в сжатом виде ? Я сам занимаюсь коммерческой разработкой ПО - никто его никогда не сжимает (я такого не видел). Парсеры, оптимизировали говоришь ... ты знаешь что такое XML, ты знаешь какое количество правил там есть и ньюансов ? Да там хоть на машинных кодах парсер пиши он будет в 10-раз уступать парсерам для бинарных протоколов, где прочитал пару байтов и уже знаешь куда и насколько сместится, с какого байта начинать считавания конкретных данных и их количество. Схемы, namespace'ы, wsdl - это просто полный ппц для разработчика. Я не понимаю тех кто изобрел xml и особенно тех кто его сейчас продвигает.

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

кстати. только что собирал себе git. формирование манов из xml заняло времени КАК МИНИМУМ НА ПОРЯДОК больше, чем компиляция исходников с -O3. писец, это то самое «удобство и ускорение», наверное. чтобы машина не простаивала, надо её чем-то занять, да.

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

>никто его никогда не сжимает (я такого не видел).

справедливости ради: AbiWord/OpenOffice.

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