критика MS Windows

[juna]

to ha
Я опять разделяю мнение вздымщик Цыпа.
Вы как-то слишком интуитивно представляете процесс тестирования.
То, что Вы описываете называется тестирование "черного ящика".
Для этого могут быть только общие рекомендации по составлению тестовых наборов, исходя из спецификации.
Наиболее обнаучено тестирование "белого ящика" - можно составлять тесты, исходя из анализа кода, методами покрытия условий, операторов и т.д.
А вообще, открытость кода, это очень мощный стимул к скорейшему нахождению, локализации и исправлению ошибок в ПО, в отличие от проприетарного ПО . И это общепризнанный тезис.

[shpeer]

Не в обиду всем присутсвующим будет сказанно , но кто-нибудь знает ответы хотя бы на один из вопросов :
1) Как заставить Word корректно работать с OLE под Linux (В частности работать с объектами MS Equation)( Были протестированны office 2003 sp3 на wine 1.06-1.10 ,estresoft wine 1.09 и под crossover linux)?
2) Как под линух редактировать документы Word с объектами MS Equation без microsoft office , получая на выходе документ Word с объектами MS Equation а не с картинками вместо формул ?
3) как быстро и без особых затрат подвергнуть [s] огню и мечу [/s] перевоспитанию редакции журналов, требующих статьи сверстанные в этой гадости ?

[worm2]

shpeer писал(а):

3) как быстро и без особых затрат подвергнуть [s] огню и мечу [/s] перевоспитанию редакции журналов, требующих статьи сверстанные в этой гадости ?

В смысле, они требуют, чтобы статьи были свёрстаны в Word'е, запущенном в Linux'е?
Давно известно, что самый простой способ победить любую организацию (не только редакцию научного журнала) --- возглавить её

[вздымщик Цыпа]

shpeer в сообщении #175467 писал(а):

3) как быстро и без особых затрат подвергнуть [s] огню и мечу [/s] перевоспитанию редакции журналов, требующих статьи сверстанные в этой гадости ?

Есть еще вариант. Вскрыть факт их преступного сговора с MS или их российским представительством и натравить на них антимонопольщиков.

По остальным пунктам могу сказать, что вы не там роете. Уповать на wine нет никаких оснований, поскольку возможности реверс-инжениринга небесконечны и всегда подобные продукты будут дефектны. Это раз. Возможности OpenOffice по сохранению документов в MSWord-подобном формате тоже ограничены по тем же причинам. Это два.

Вы можете попробовать MS Windows с MS Word под эмуляторами типа VMWare. В этом случае есть некоторая надежда на успех.

[juna]

shpeer в сообщении #175467 писал(а):

Как под линух редактировать документы Word с объектами MS Equation без microsoft office , получая на выходе документ Word с объектами MS Equation а не с картинками вместо формул ?

Установите пакет openoffice.org-math, по-моему, он обеспечивает совместимость с MS Equation - одним из самых кривых продуктов от MS.

[yk2ru]

juna в сообщении #175502 писал(а):

Установите пакет openoffice.org-math, по-моему, он обеспечивает совместимость с MS Equation - одним из самых кривых продуктов от MS.

А какой самый лучший продукт от MS? (Excel?)

[shpeer]

вздымщик Цыпа писал(а):

shpeer в сообщении #175467 писал(а):

3) как быстро и без особых затрат подвергнуть [s] огню и мечу [/s] перевоспитанию редакции журналов, требующих статьи сверстанные в этой гадости ?

Есть еще вариант. Вскрыть факт их преступного сговора с MS или их российским представительством и натравить на них антимонопольщиков.

По остальным пунктам могу сказать, что вы не там роете. Уповать на wine нет никаких оснований, поскольку возможности реверс-инжениринга небесконечны и всегда подобные продукты будут дефектны. Это раз. Возможности OpenOffice по сохранению документов в MSWord-подобном формате тоже ограничены по тем же причинам. Это два.

Вы можете попробовать MS Windows с MS Word под эмуляторами типа VMWare. В этом случае есть некоторая надежда на успех.

Дык к wine можно прикрутить dll от windows , и судя по слухам некоторые люди добились успеха, однако реультат крайне неустойчив по сочетаниям версий windows/wine/office а народ темнит.

Цитата:

juna в сообщении #175502 писал(а):
Установите пакет openoffice.org-math, по-моему, он обеспечивает совместимость с MS Equation - одним из самых кривых продуктов от MS.

Уж лучше OOLatex



PS
Это был крик души
пожалуйста не продолжайте флуд по этому поводу..

Разве кто нащупает конфигурацию ...

[ha]

juna писал(а):

to ha
Наиболее обнаучено тестирование "белого ящика" - можно составлять тесты, исходя из анализа кода, методами покрытия условий, операторов и т.д.
А вообще, открытость кода, это очень мощный стимул к скорейшему нахождению, локализации и исправлению ошибок в ПО, в отличие от проприетарного ПО . И это общепризнанный тезис.

Это общепринятое заблуждение линуксоидов. Современная разработка софта - это test-driven development, когда тесты составляются до того, как есть какой-то код. Да и тестеры (программистов пишущих unit-тесты я к ним не отношу) во всех известных мне организациях тестируют приложения практически как черный ящик.

В тех open-source проектах, в которых я разбирался подробно, доля ошибок исправленных пользователями очень мала (на глаз я оцениваю ее как от 0.1% до 10%) по сравнению с ошибками исправляемыми разработчиками. Не говоря уж о том, что в приложении для широкого круга пользователей нельзя надеятся на исправление ошибки в ядре/компиляторе - нужно в обязательном порядке ее обходить.

[вздымщик Цыпа]

ha в сообщении #175583 писал(а):

Это общепринятое заблуждение линуксоидов. Современная разработка софта - это test-driven development, когда тесты составляются до того, как есть какой-то код.

Это распрастраненное заблуждение проприетарщиков. Им кажется, что если они разделят пишущих ТЗ (белых людей), кодеров и тестеров (черных людей) они улучшат процесс разработки. На самом же деле они ее только удешевляют. Нормальные деньги можно платить только первым (их немного), а остальные (их много) работают практически за еду. Как результат они имеют то, что имеют, а именно дешевый и некачественный продукт, который можно продвинуть в сторону продажи только нерыночными методами.

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

ha в сообщении #175583 писал(а):

В тех open-source проектах, в которых я разбирался подробно, доля ошибок исправленных пользователями очень мала (на глаз я оцениваю ее как от 0.1% до 10%) по сравнению с ошибками исправляемыми разработчиками.

Назовите пожалуйста их поименно и может быть я поясню с чем это связано.

ha в сообщении #175583 писал(а):

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

Я 4 раза прочитал эту фразу и так и не понял, что Вы имели в виду. Перескажите ее пожалуйста другими словами.

[sdfs]

вздымщик Цыпа писал(а):

ha в [url=http://dxdy.ru/post175583.html]
[quote="ha в сообщении #175583 писал(а):

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

Я 4 раза прочитал эту фразу и так и не понял, что Вы имели в виду. Перескажите ее пожалуйста другими словами.

Надо полагать имелось в виду то , что проприентарщики не могут послать патч разработчикам ядра windows, и надеятся что пропатченное ядро будет включено в репозитории вместе с их программой .
Бедные ... [/quote]

[ha]

вздымщик Цыпа писал(а):

Это распрастраненное заблуждение проприетарщиков. Им кажется, что если они разделят пишущих ТЗ (белых людей), кодеров и тестеров (черных людей) они улучшат процесс разработки. На самом же деле они ее только удешевляют. Нормальные деньги можно платить только первым (их немного), а остальные (их много) работают практически за еду. Как результат они имеют то, что имеют, а именно дешевый и некачественный продукт, который можно продвинуть в сторону продажи только нерыночными методами.

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

Ну в составлении ТЗ программисты участвуют очень часто. Во-вторых если вы уберете тестеров, то программисты от этого лучше программить не будут и крутые тестеры из них из ниоткуда не возьмутся. Не говоря уж о том, что желание заниматься тестированием как можно меньше побороть очень трудно. Другое дело, когда это твоя работа и тебя за нее спрашивают. Еще мы забыли специалистов по юзабилити. Этим программистам точно лучше не заниматься.

Цитата:

ha в сообщении #175583 писал(а):

В тех open-source проектах, в которых я разбирался подробно, доля ошибок исправленных пользователями очень мала (на глаз я оцениваю ее как от 0.1% до 10%) по сравнению с ошибками исправляемыми разработчиками.

Назовите пожалуйста их поименно и может быть я поясню с чем это связано.

Free pascal compiler (примерно 3700 багов closed/100 багов resolved (не знаю есть ли разница), пользователями предложено 2 патча), jedit (примерно 3000 багов closed, 177 патчей принято от пользователей/разработчиков).

Цитата:

ha в сообщении #175583 писал(а):

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

Я 4 раза прочитал эту фразу и так и не понял, что Вы имели в виду. Перескажите ее пожалуйста другими словами.

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

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

[вздымщик Цыпа]

ha в сообщении #175665 писал(а):

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

Крутые тестеры — это какие? Те, которые по внесенным изменениям сами определяют что нужно в тесты добавить, что убрать, что изменить? Не верю, что такие бывают. Если тестер это умеет, то он уже не тестер, а тоже программер и использовать его только в таком качестве — непроизводительно транжирить его возможности. Не, фаза тестирования в жизни продукта конечно же нужна, но иметь на это отдельных людей, я считаю необязательно. Грубо говоря, чем долго и муторно им объяснять, что и как надо тестировать, легче это проделать самому. Ну а насчет того, что программера это делать не заставишь, то это уже зависит от программера и того, кто заставляет Хороший код тоже не всякого заставишь писать.

ha в сообщении #175665 писал(а):

Еще мы забыли специалистов по юзабилити. Этим программистам точно лучше не заниматься.

Тут Вы совершенно правы. Пользовательский интерфейс (оконный) должны дизайнить совершенно посторонние от программирования люди. Когда за это беруться программисты, результат как правило получается хуже некуда. Ну да, в этом случае в команде разработчиков должен быть дизайнер. Но при этом именно в команде, а не сам по себе.

ha в сообщении #175665 писал(а):

Free pascal compiler (примерно 3700 багов closed/100 багов resolved (не знаю есть ли разница), пользователями предложено 2 патча)

Я не очень разобрался в их bagtracker'е, но тыкая наугад в репорты, сразу наткнулся (буквально третья и пятая проба):
http://bugs.freepascal.org/view.php?id=11856
http://bugs.freepascal.org/view.php?id=12467
Явно сторонние люди присылают патчи, не к самому компайлеру, а основной сопутствующей библиотеке (FCL) и их принимают. Так что все в порядке, никакой аномалии не видно. А то, что не шлют патчи к самому компайлеру, можно объяснить его экзотичностью. Ведь в отличие от GNU/Pascal FPC реализует Борландовский диалект Паскаля и очень может быть, что он сам есть единственный серьезный продукт написанный на этом диалекте При таких обстоятельствах несложно собрать всех серьезных программистов, заинтересованных в его развитии, в команде разработчиков и все правки становятся «внутренними».

ha в сообщении #175665 писал(а):

jedit (примерно 3000 багов closed, 177 патчей принято от пользователей/разработчиков).

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

ha в сообщении #175665 писал(а):

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

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

ha в сообщении #175665 писал(а):

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

Очень сильно зависит от деталей. Во-первых, обход может сопровождаться большими дефектами в работе. Скажем, если я использую 'epoll', то теоретическое присутствие в мире систем с ядром <2.6.8, в которых он еще не реализован, не является поводом писать для них workaround на 'poll', поскольку в таком случае продукт не будет обладать заявленными характеристиками, а это гораздо важнее. Но к счастью, в линуксовом мире принято обновлять систему с выходом нового соответствующего дистрибутива. Например, в случае с Ubuntu, это каждые полгода. А <2.6.8 — это ядро трехлетней давности и его потенциальное наличие можно не учитывать.

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

ha в сообщении #175665 писал(а):

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

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

[ha]

вздымщик Цыпа писал(а):

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

Нет, которые внимательно читают user-мануал и проверяют множество крайних случаев и все основные варианты использования приложения, а также вещи, которые обычно подразумеваются, но не указываются в мануалах (например возможность навигации с помощью клавиатуры в gui-приложениях, сохранение recent colors при повторном открытии диалога выбора цвета и.т.д.). Unit-тестами разумеется должны заниматься только программисты.

Цитата:

Явно сторонние люди присылают патчи, не к самому компайлеру, а основной сопутствующей библиотеке (FCL) и их принимают. Так что все в порядке, никакой аномалии не видно. А то, что не шлют патчи к самому компайлеру, можно объяснить его экзотичностью. Ведь в отличие от GNU/Pascal FPC реализует Борландовский диалект Паскаля и очень может быть, что он сам есть единственный серьезный продукт написанный на этом диалекте При таких обстоятельствах несложно собрать всех серьезных программистов, заинтересованных в его развитии, в команде разработчиков и все правки становятся «внутренними».

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

Но как видите с компилятором - ситуация совершенно другая. Ему открытость не помогает.

//offtopic: На счет диалектов паскаля я вас не понял - fpc полностью поддерживает устаревший тубро паскаль, которым сейчас никто не пользуется, свой режим (имеются доп. возможности, которых нет в дельфи) и режим совместимости с дельфи (разумеется не полной). На других паскалях кроме этих режимов fpc и дельфи никто не пишет.

Цитата:

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

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

Цитата:

Очень сильно зависит от деталей. Во-первых, обход может сопровождаться большими дефектами в работе. Скажем, если я использую 'epoll', то теоретическое присутствие в мире систем с ядром <2.6.8, в которых он еще не реализован, не является поводом писать для них workaround на 'poll', поскольку в таком случае продукт не будет обладать заявленными характеристиками, а это гораздо важнее. Но к счастью, в линуксовом мире принято обновлять систему с выходом нового соответствующего дистрибутива. Например, в случае с Ubuntu, это каждые полгода. А <2.6.8 — это ядро трехлетней давности и его потенциальное наличие можно не учитывать.

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

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

[Nik_Svan]

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

[вздымщик Цыпа]

ha в сообщении #176672 писал(а):

Нет, которые внимательно читают user-мануал и проверяют множество крайних случаев и все основные варианты использования приложения, а также вещи, которые обычно подразумеваются, но не указываются в мануалах (например возможность навигации с помощью клавиатуры в gui-приложениях, сохранение recent colors при повторном открытии диалога выбора цвета и.т.д.).

Видать мы совсем о разного рода приложениях говорим. Ну да, я постоянно отталкиваюсь от того, что пишу сам, а там никаких гуев нет и в помине и тестер без дебагера ничего интересного не увидит Согласен, бывают и другие. Но опять же вернемся к разнице между проприетарщиками и опенсорсем. Поскольку за открытое ПО непосредственно за копию денег обычно не взымают, то нет смысла скрывать продукт до релиза. Как правило, он доступен всем желающим. Каждый дистрибутив имеет одновременно несколько версий. На примере Debian или Ubuntu — stable, testing (будущий stable) и unstable. И очень многие из интереса к новым фичам, не вошедшим в stable, ставят себе testing. Вот они и составляют огромную армию добровольных тестеров, чем сильно обегчают жизнь разработчикам, поскольку забираются в такие уголки, куда штатный тестер и не додумается заглянуть

ha в сообщении #176672 писал(а):

Но как видите с компилятором - ситуация совершенно другая. Ему открытость не помогает.

Этому не помогает. А вот GCC помогает. Можно глянуть в ChangeLog (он есть за всю историю), сравнить со списком MAINTAINERS и увидеть большое количество правок от сторонних людей и в библиотеки, и в компайлер. Более того, когда-то (до 97 года) GCC развивался кулуарно, т.е. почти как пропоприетарный продукт, а потом сначала от него отпочковалась публичная ветка (EGCS), еще потом они снова слились, но уже с публичной разработкой. Разница была разительная. Собственно, именно после этого в GCC таки появился нормальный плюсовый компайлер и к этому очень немало приложились сторонние разработчики, не входящие в команду.

ha в сообщении #176672 писал(а):

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

Может большинства количественно, но никак не большинства качественно. Очень многое ПО существует в одном-двух вариантах и им пользуются как те, так и другие и никак мимо не проскочить. Текстовые редакторы, разумеется к таким не относятся. Их наплодили как грязи. У каждого есть минимум один свой редактор. У меня, кстати тоже есть, очень хороший , но лет 10 я им не занимался и в паблик не выкладывал.

ha в сообщении #176672 писал(а):

На закрытых серверах ОС может не обновляться с момента покупки - т.е. до 10 лет.

Если на закрытый сервер ничего нового не ставят 10 лет, то можно ОС и не обновлять. Если что-то ставят, из его 10 летней давности дистрибутива, то тоже все нормально, оно внутри себя согласовано. Так что, я не понимаю, что Вы имеете ввиду? На какой-нибудь RedHat 4.2 поставить package от Ubuntu 8.10 ? Так не поставится и это правильно.

ha в сообщении #176672 писал(а):

На десктопах пользователь совершенно аналогично может не знать как обновлять ядро (я, например, не знаю).

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

ha в сообщении #176672 писал(а):

Да и в больших организациях тоже может действовать принцип "работает - не трогай".

Либо пользователь имеет право самостоятельно ставить себе софтвер, либо не имеет. Какие-то промежуточные состояния, типа приложения можно, а обновления ядра — нет, мало осмысленны.