Направление развития софта

конкретнее

flash и acrobat

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

Вот тебе Critical баг из недавней практики.

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

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

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

Полчаса гуглежа, и проблема решена

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

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

Потому что gnome2 - RIP.

А еще мне лень подключать сторонние репы, чтобы поставить гнум2.

а все баги исправляют практически сразу

в сферическом вакуумном? 4.2, буде есть примеры обратного, что вошло в поговорку про отсрочку перехода на новую версию продукта «до первого сервиспака...»

Вы забываете о том, что исправляя один баг, вносите 3 новых.

вы думаете, хоть одному кодеру платили за исправление своих багов и рефакторинг???

Знаю не одного кодера, которым в том числе за это платят.

УМВР.

Патаму шта старые баги править неинтересно, плодить новые гораздо более увлекательно :-)

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

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

Ну вот смотри. Есть баги вроде 12309, на которые репорты уже давно есть. Тестировщики тут уже свое дело сделали, осталось исправить.

Забыл сказать про пропреитарные продукты. Там все зависит только от рынка. Баги будут правиться только если могут вызвать отток клиентов, как и оптимизация. В других случаях оно «экономически не выгодно» выгоднее бороться за новых клиентов, поднимая функционал. При накоплении критической массы багов все пишется практически с нуля, ставится новая цифирька, маняется немного логотип и продается как «новое, современное решение, в 2(3/4/5...) раз быстрее и функциональнее.

При учете что долго ни кто не мог его воспроизвести с вероятностью 100% - не мудрено. ведь о баге надо знать не только что он есть, но и при каких условиях он есть.

Честно говря не следил пристально за ним, но, как понял, его долго искали, несколько раз думали что поправили, ан нет. в каком сейчас состоянии - не знаю.

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

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

Как мне помнится, 4 КДЕ тем и прославился что многих отпугнул косяками. Потом опомнились и начали править.

Критическая уязвимость в Adobe Flash Player Новая критическая уязвимость в Adobe Flash Player, Adobe Reader и Acrobat Adobe исправит критическую уязвимость Adobe Reader только через месяц Критическая уязвимость в Adobe Reader. Патч ожидается во вторник. В Adobe Flash опять найдены критические уязвимости В Adobe Flash опять найдены критические уязвимости Критическая уязвимость в Adobe Flash Player for Linux Уязвимость в Adobe Flash, позволяющая перехватывать буфер обмена

критическая уязвимость != критический баг, try again

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

/me посмеялся. vmware workstation на рабочей машине падает по 3 раза на дню, видел несколько ошибок с гордым описанием not_implemented. вроде недешевый ынтырпрайзный софт. релизный matlab 2010a у меня на личной машине просто сыпал эксепшенами за каждым чихом. win7 даже SP1 не сделал надежной, всегда внезапные косяки.

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

VMWare никогда не пробовал, поэтому спорить не буду. А вот виртуалбокс всегда только радовал (да, у него есть свободная версия, но разрабатывает все равно корпорация).

А вот виртуалбокс всегда только радовал

Он не все адекватно поддерживает, к сожалению. vmware умеет правильно больше ОС.

И API у него монструозный через COM/XPCOM, в отличие от няшного сишного (нестабильного и со странностями) у vmware. Я молчу про java-бидинги, где название пакета зависит от версии виртуалбокса.

Хотя в целом приятен, ничего не скажешь, и к ресурсам менее требователен.

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

vurdalak

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

насколько я знаю, все эти твои примеры - не более чем одинаковые системы совершенно разных болезней. Например у меня в KDE 4.7.4 плазма не падает, вроде у других - тоже. Однако, в более ранних и в более поздних релизах плазма падает. Но с чего ты взял, что это связана с одной и той-же ошибкой? Ты что серьёзно думаешь, что в KDE4.0 ошибочно записали х=6, и плазма падает, т.к. х должно быть равно 17, что и исправили в 4.7.4, а в 4.8 опять написали х=6? Вредительство? Саботаж? Происки мысы? Согласись - это всё бред. Тоже самое касается и пресловутого 12309, который то откроют, то закроют. У меня например его нет. Хотя в ядре 3.х он опять открыт с 7го января этого года.

В коммерческом софте почему-то не ленятся тестировать и исправлять

Ну-ну.

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

дык займись.

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

э...

не люблю крестовые и шлицевые отвёртки. Вот был-бы там отбойный молоток, а у меня куча времени - всё-бы раздолбал!

//fixed

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

Если я уйду в изучение сей, я не буду успевать следить за джавой.

потому я не знаю явы ;)