Весело е, като репортнеш бъг, а после се окаже, че са го фикснали без да искат, но все пак след като е репортнат.
Интересното е, че някак си по случайност, бъгавият код е бил оправен поради съвършено други съображения, без връзка с конкретния бъг репорт.
Преди много време, бях чел за една псевдонаучна теория, че всяко нещо което се случва за първи път, става много по-трудно отколкото когато се случва за втори път. Например, ако в една лаборатория проведат някаква капризна химична реакция за пръв път. Втора лаборатория ще получи по-лесно същият резултат, даже без да знае за опитите на първата лаборатория.
Та възниква въпросът, дали и тука няма нещо подобно – репортването на бъг увеличава вероятността той да бъде фикснат даже и никой да не му обърне внимание.
При това говорим за доста голям проект. Вероятността случайно да променят точно тия редове клони към нула.
Няма гаранция че първата и втората лаборатория са именно първата и втората, тея неща Мада Нейча си ги движи у голема картинка и което наистина и требе бива създадено. От наша гледна точка най-доброто е да ги експлойтваме в наща нишова част от пейзажа и наш интерес като падне сгодица, а именно да претендираме че ние сме първата лаборатория :)
Тук навлизаме в загадките на статистиката, репорт на бъг е просто индикатор че бъг има и е от такова ниво че на някой му пречи сериозно та си е направил труда да писне. Това ако го сравним с друга контролна група където бъг има ма никой не го репортва, демек нивото му е по-ниско, означава просто че по-често оправят по-сериозните бъгове, което е ... ми нормално не само за професията а и по принцип, са ако Гинка на Бамбо мечи щото е гладна а Генка само мляска се сещай на коя ще даде първо
Ами не. Работата е там, че точно този бъг на никой не пречи, защото условията за активирането му са много екзотични. Аз го открих след моя грешка в кода, която водеше до такива условия и това се получи само защото се занимавам на много ниско ниво с X11 протокола.
Аз затова си направих труда да го репортна, защото иначе шансът някой друг да го срещне и репортне е практически равен на нула. Но и на мене този бъг не ми пречи, защото никога не се активира.
Друг подобен бъг е този: The system hangs, но реалният проблем е зарит много дълбоко в xorg сървъра и не съм сигурен, че въобще някога ще го фикснат. Още повече, че и той на никой не пречи.
Ако на някой му е интересно как да зависне GUI-то на Linux, да чете по връзките. 
Ти виждаш ли някакво логическо противоречие тук:
"някак си по случайност, бъгавият код е бил оправен поради съвършено други съображения, без връзка с конкретния бъг репорт"
"Работата е там, че точно този бъг на никой не пречи, защото условията за активирането му са много екзотични"
По бръснача на Окам точно тоя бъг на някой му възникнал и са го оправили, сега вече дали му е попречил като вземе жената боб ще хвърля и ще дам аргументирано мнение. А това дали "на никой не пречи" е същото като "асемблера е най-добър за всичко" - твое мнение и покриващо твоята визия, нали.
Така ли се оправят бъгове в Линукс - като се премахнат функционалности защото евентуално може да са бъгави( drop shadows в случай)?
Доколкото се ориентирам, нищо такова няма. Сенките могат да се рисуват само в композитен режим на екрана. Може би нещо такова са оправяли. Във всеки случай, никакви функционалности не са махани.
ГУЯ на луникс (и там джамци, ябълки) е история, веба пък е безформена чекия, така управлява Мада Нейча, се не уйдисва :)
М-м-м-много спорно твърдение. Толкова спорно, че чак лъжливо.
А за уеб интерфейса май ще се съглася...
ГУИ интерфейсите в момента са или барокови апендикси от времената когато компютъра беше на маса или недоклатени вебаджийски чекии или още по-недоклатени мобайл чекии. Разкошни времена общо взето, квото и да направи човек нема как да е в грешка спрямо генерално насрания голям пейзаж :)
Факта, че chromeos реално се провали, както и firefox os доказва, че не си прав. Когато една концепция се докара до крайност, резултата рядко е много добър.
Поначало идеята че конете на големите играчи дефинитивно показват кво се случва в кушията е измамна, те самите големи сега играчи някога са били underdogs :)
От моята практика последните няколко години най насраните бъгове с които съм се борил са:
- хардуерен бъг в един секюрнат Broadcom ARM cortex A7 който си осираше контекста при прекъсване и смяна на нишка по време на ITE (if-then-else) инструкция - резултата беше, че изпълняваше и then и else инструкциите което водеше до случайни грешки при array bounds checks след което си крашваше юнашки в произволен момент толкова рядко, че се репродуцира с дни. Ама пък при хиляди устройства без човешко наблюдение по разни вендинг машини това беше на ден-два да има рапорт за краш някъде из европата. Който е дебъгвал на толкова ниско ниво предполагам може да си представи какъв ад е да се излови и фиксне подобен бъг.
- едновременно полиране и ползване на прекъсвания на УАРТ 16550 който по дизайн има недомислие, че щом прочетеш статуса при полиране изчиства заявката за прекъсване т.е. при едновременно ползване нишката която ползва полиране изчиства прекъсването на другата нишка която пък работи с прекъсвания т.е. никога не идва прекъсване, че буфера е празен и трябва да се прати следващия символ. И тъй като това беше в лог кода беше защитен с един семафор за да не се бият няколко нишки и да си омазват логовете. И тъй като нямаше таймаут нито хардуерно лаещо куче защото нали хардуера няма как да се бърне и да не работи една по една всички нишки които логват увисваха на опашката на неосвободения семафор в резултат на практика забиваше целия терминал също горния случай. Да ама като е защитен процесора не може и да го дебъгва човек - няма jtag единствено пишеш в лога който пък забива заради семафора т.е. кошмар за дебъгване на проблем който става изключително рядко. И цялата работа защото са спестили няколко цента за едно лаещо куче да рестартира всичко.