Jak to jest z tymi błędami i opensource?

Zastanawiam się od jakiegoś czasu na ile to całe gadanie o tym, ze w open source bledy likwiduje sie natychmiast a w zamknietym oprogramowaniu po czasie. Mielismy ostatniuo przyklad kiedy w IE pojawil si epowazny blad i microsoft praktycznie natychmiast wydal poprawke to wszystkich wersji IE w tym 6.0 (ktorej nie powinien juz nikt uzywac bo to grat, ale pewnie pobedziemy sie go dopiero jak ludzie zrezwygnuja z winxp - choc to tez grat :D).

wracajac do tematu, czy da sie udowodnic ze faktycznie bledy wykryte w otwartym oprogramowaniu latane sa szybciej, czy to moze w rzeczywistosci jest tak, ze w OS one MOGLYBY byc latane szybciej, bo przeciez kazdy moze to zrobic, ale nie koniecznie robi.

UPDATE: Tak mogło wynikać z mojego pytania, ale nie chodzi mi oczywiście tylko o błędy bezpieczeństwa do których wykrycia potrzeba albo przeglądania kodu albo black hata który błąd wykorzysta. Chodzi mi tez, a moze przedewszystkim o takie normalne bledy ktore wychodza przy uzytkowaniu. I ktore "odkrywa" zwykly uzytkownik ktory o kodzie pojecia nie ma i jedyne co moze zrobic to zglosic gdzies ze znalazl blad. Zakladajac wiec ze zglosil "jak sie uruchomi foo z parametrem shmo to sie foo konczy seffaultem" to czy to czy projekt jest OS czy CS ma Waszym zdaniem znaczenie?

na_luzie

2 lata, 3 miesiące temu | edytowane przez: szaman 141111442

Odpowiedz na pytanie

Ulubione (0)
Dodaj komentarz
Oznacz jako niewłaściwe

Odpowiedzi: 7

2 lata, 3 miesiące temu
edytowane przez: michu
Pytanie społeczności

5
Nie do końca. Wszystko zależy od społeczności wokół projektu. Przy wielkoprofilowych projektach open source, gdzie jest aktywna społeczność, wielu pogramistów - na pewno znalezione błędy usuwane są szybciej. Krótszy cykl wydawania produktów ułatwia też szybkie dotarcie poprawki do użytkowników. Ale takie projekty to jest niewielki ułamek ogólnej liczby projektów open source - w ogólnym przypadku, śmiem twierdzić że oprogramowanie closed source, którym zajmuje się kilka (naście/dziesiąt) osób, którym za to ktoś płaci, jest naprawiane szybciej.

Ale to dotyczy błędów, które zostały znalezione. Co z samym ich wyszukiwaniem?

No i tu się pojawia największy mit open source - przypowiastka o większej liczbie oczu patrzących na kod, co ma się przekładać na większą wykrywalność błędów.

To tak jak z tym, że gdyby wszyscy ludzie byli przyzwoici, to wszystkim by się znacznie lepiej żyło. Możliwe? W teorii tak. Dobre? Jak najbardziej. Wykonalne? W praktyce nie.

Kto z Was ostatnio, altruistycznie (tzn. nie będąc członkiem zespołu), przeglądał kod aplikacji open source? I to nie z ciekawości "jak to działa", ale na tyle uważnie i z takim zrozumieniem, by wykryć cudze błędy? Poza nielicznymi specjalistami od bezpieczeństwa systemów, którzy takim rzeczami zajmują się zawodowo (i, ciekawostka, pewnie biorą za to pieniądze od instytutu który ich zatrudnia), oraz osobami, które chcą zachować informacje o lukach dla siebie i na swój użytek, mało kto to robi.

Obawiam się, że większość błędów w projektach open source jest znajdowana dokładnie tak, jak w projektach closed source - przez ich użycie, mniej czy bardziej świadome black box testing.

Jedyna przewaga projektów open source w kontekście naprawiania błędów - mówię jedyna, ale nie mówię że mała, bo jest ogromna - jest taka, że jeżeli się posiada odpowiednią wiedzę, to po natrafieniu na błąd który nam żyć nie daje można go samodzielnie poprawić i wysłać do autorów patcha, po czym cieszyć się działającą aplikacją nie czekając na oficjalny release poprawki. Sam kilka razy z tej możliwości skorzystałem i przyznaję, daje to sporą satysfakcję... :)

2 lata, 3 miesiące temu
edytowane przez: przemelek
Pytanie społeczności

3
Ja może zacznę od innej strony niż inne osoby odpowiadające :-)

Microsoft uznaje, że w ich oprogramowaniu w momencie wypuszczenia średnia gęstość błędów to 0.5 błędu na 1 KLOC [tysiąc linii kodu], jak pamiętam w sprzęcie telekomunikacyjnym za standard przyjmowano 2-3 defekty na 1000 linii. Mowa tu o błędach już w gotowym produkcie.

Dla porównania wg. analiz statycznych przeprowadzonych w 2006 roku na kilku projektach Open Source [np. na Python'ie czy Samba'ie] średnia gęstość defektów wynosiła 0.3 na 1 KLOC.

Bazując na tym opracowaniu z 2004 roku w kernelu 2.6 Linuksa wykryto niecałe 1000 błędów na 5,7 mln linii kodu, czyli około 0.17 błędu na KLOC.

Dla porównania oprogramowanie dla wahadłowców ma 1 błąd na 500 KLOC, czyli 0.002 błędu na KLOC.

Można jednak stwierdzić, że bazując na gęstości błędów produkty Open Source mają ich mniej niż produkty closed source.

Zawdzięczać to mogą paru rzeczą, po pierwsze choć osoby wyżej piszące uznają to za mało istotne to code review jest jedną z najlepszych broni przed defektami w kodzie, Te 0.5 błędu na KLOC w Microsoft'cie to zapewne efekt właśnie code review. Jednak jedno to code review, które samo w sobie jest dobre, a drugie to ciągłe inspektowanie źródeł w Open Source. Procesy w wielu firmach są tak zbudowane, że jak developer nawet zauważy błąd w innej części kodu to nie może go zmienić bez uruchomienia całej procedury decyzyjnej, która może uznać, że ten błąd jest nieważny, w Open Source to tak nie działa. Na dodatek w czasie inspekcji kodu w firmie inspektuje się zwykle tylko kod zmieniony, czyli zwykle każda linia została przejrzana tylko raz... inna sprawa, że inspekcja, inspekcji nie równa, a zwykle jest się daleko od faganowskiego ideału ze 100 liniami przejrzanymi na godzinę.

Projekty Open Source mają też tą przewagę, że nie ma w nich zasady "działa, nie rusz". Zasada ta jest nadal stosowana w wielu firmach, co powoduje, że kod z czasem obrasta w zestawy workaround'ów, które zwiększają szansę na nowe błędy, do tego w projektach Open Source istnieje też "ochrona" przed młodzieżowym podejściem "to jest do bani, przepiszmy to" bo projekty Open Source to merytokracja gdzie poziom mocy decyzyjnej zależy od zasług.

No i projekty closed source są pisane dla klientów i dla pieniędzy, czyli często istnieje w nich pokusa by pisać szybko i tanio.

2 lata, 3 miesiące temu
edytowane przez: mrbox
Pytanie społeczności

2
Na pewno 'mogłyby' i na pewno w części projektów są łatane szybciej. Ale jak wszędzie- można spotkać projekty porządnie prowadzone, którymi ktoś się opiekuje i ciągle tam dłubie i naprawia błędy, a można spotkać też takie, gdzie stosowany jest olewizm i to userzy się mają martwić.

A tak ogólnie, to wydaje mi się, że błędy w OS są przede wszystkim szybciej wykrywane- czas załatania bywa różny, ale na pewno po przejrzeniu kodu można szybciej wykryć błędy, niż przy kodzie zamkniętym- nie działa się na ślepo.

2 lata, 3 miesiące temu
edytowane przez: matekm
Pytanie społeczności

2
Ja jestem pewny jednego - krytyczne błędy w Otwartym Oprogramowaniu naprawiane są dużo szybciej niż analogiczne w zamkniętym. Wystarczy spojrzeć na raporty secuni dotyczące przeglądarek internetowych

Firefox: http://secunia.com/advisories/product/25800/

Chrome: http://secunia.com/advisories/product/25720/

IE: http://secunia.com/advisories/product/12366/

Ma to duży związek z tym, że w większości Otwartych projektów stosuje się jakąś odmianę Agile i jak już taki błąd się pojawia to ktoś go po prostu "sobie przydziela". W projektach zamkniętych natomiast istnieje "presja czasu" na wydanie kolejnej wersji z nowymi funkcjonalnościami - zasoby czasu nie są nieskończone i czasami olewa się błędy bezpieczeństwa (vide MS). Dodatkowo stosuje się "cięższe" metodyki wytwarzania oprogramowania co spowalnia cykl wydawniczy/

2 lata, 3 miesiące temu
edytowane przez: wariat
Pytanie społeczności

2
Myślę, że największą przewagę Open Source zyskuje tu dlatego, że generalnie użytkownicy Otwartego Oprogramowania najzwyczajniej częściej zgłaszają znalezione błędy. Robią to oczywiście dlatego, że mają znacznie większe szanse niż w przypadku projektów zamkniętych, że ich zgłoszenie zostanie zauważone. To taki układ „zróbmy wspólnie fajny soft, nie umiesz go napisać, to po prostu powiedz nam gdzie coś spierdzieliliśmy”. I to generalnie działa. W zeszłą sobotę okazało się, że autouzupełnianie nazw plików wywala basha jeśli w nazwie pliku jest gwiazdka, wysłałem zgłoszenie o 22:17, tego samego dnia o 22:07 pojawił się patch (no dobra, 10 minut wcześniej ale 6 stref czasowych dalej :D). I takich przypadków znam dziesiątki, czyli nie można powiedzieć, że to nie działa bo działa.

Z drugiej strony jak zauważył michu są projekty i projekty. Tylko to samo dotyczy zarówno otwartych jak i zamkniętych przypadków. Bywają takie (i tu i tu) gdzie można zgłaszać mega upierdliwy błąd miesiącami i wszyscy mają to gdzieś. Tylko tu znowu OS ma bonus bo w końcu jak już nie da się zmusic autora to można poprawić samemu, a jak jest zamknięte to można co najwyżej szukać alternatywy, a nie zawsze się da.

Na koniec, to, że samo otwarcie kodu nie wystarczy aby błędy z niego uciekły to chyba jasne. Kluczem do jakości jest po prostu społeczność. Im więcej użytkowników tym większe szanse, że pojawią się tacy którzy będą chcieli i potrafili wysłać zgłoszenie o błędzie.

2 lata, 3 miesiące temu
edytowane przez: tomaszs
Pytanie społeczności

1
Pod koniec 2008 roku uTest przeprowadziło rywalizację między 1300 testerami z 68 krajów, którzy mieli za zadanie znaleźć bugi w Firefoxie, Google Chrome i Internet Explorerze. Oto wyniki:
- IE - 356 bugów
- Firefox (Open Source) - 207 bugów
- Chrome (na bazie Open Source) - 461 bugów
Po pierwsze więcej osób zgłosiło się do debugowania Firefoxa, co zapewne wynikało ze znajomości kodu tej aplikacji. A więc jest to pozytywny aspekt otwartości kodu - ludzie chętniej uczestniczą w jego debugowaniu. Z drugiej strony jednak, liczba błędów znalezionych raczej nie wskazuje na to, żeby była to bardziej zabugowana aplikacja niż IE. Jeżeli Firefox byłby napisany tak samo jak IE to zapewne dzięki otwartości liczba znalezionych bugów byłaby większa znacznie. Przypuszczalnie więc jakość kodu Firefoxa jest po prostu lepsza.

Z kolei raport Cenzic z końca 2009 ujawnił, że open sourceowy Firefox miał najwięcej znalezionych błędów spośród przeglądarek. Pytanie więc - czy to otwartość powoduje, że tyle błędów jest znalezionych i łatanych? Czy zamknięte przeglądarki mają te błędy ukryte przez lata (nawiązuję do ostatniego major bug w IE).

Jeżeli spojrzymy na świat systemów operacyjnych to sytuacja wygląda następująco:

Niektórzy wskazują też, że otwartość nie ma większego znaczenia, bo liczba bugów zależy od liczby linii kodu. Dlatego stosuje się zwyczaj izolacji kodu o dużych uprawnieniach aby dokładnie kontrolować jego działanie, a systemy takie jak OpenBSD są rozwijane wolniej, aby ustrzec się przed niekontrolowanym wzrostem. Jest to dosyć racjonalne, ponieważ liczba linii kodu powoduje komplikację projektu i wzrost jego złożoności, co może powodować pojawianie się błędów.

Z kolei w 2004 naukowcy ze Stanford i Cambridge Mellon University przeprowadzili testy jakości kodu dystrybucji Linuxa i Windowsa i okazało się że po zakończeniu testów wiele z nich zostało już naprawionych przez programistów Linuxa.

A więc wygląda na to, że otwartość kodu sprzyja jakości kodu na kilka różnych, ciekawych sposobów. I każdy z nich z osobna jest dobrym argumentem żeby prowadzić otwarty projekt.

2 lata, 3 miesiące temu
edytowane przez: nilphilus
Pytanie społeczności

0
Trudno porównywać M$ do projektu Open Source szczerze powiedziawszy, z jednej strona firma dysponująca świetnymi (drogimi) specjalistami, a z drugiej losowa liczba wolontariuszy, o losowych umiejętnościach (ale w znacznej większości sporych). Oczywiście spore znacznie ma rozmiar aplikacji, bo w mniejszych projektach łatwiej coś znaleźć osobie która doszła do zespołu (co w Open Source jest częstsze niż komercyjnych) niż w rozbudowanych - nie wspominając że firmy komercyjne raczej bardziej dbają o pisanie dokumentacji ( a przynajmniej powinny ).

Btw. To że łatwiej znaleźć błąd/lukę poza dobrymi stronami ( naprawa ) ma też spory minus, można równie łatwo (i tak trudno ;-) ) znaleźć i wykorzystać tą lukę.