Krótki raport o stanie błędów w jądrze Linux
- Dodano: 4 May 2008
- Wprowadził: optimizationkit
- Komentarze: 65
Natalie Protasevich wysłała raport w którym opisała aktualny stan błędów w jądrze Linux na podstawie błędów zarejestrowanych w bugzilla.kernel.org. Po podzieleniu wszystkich raportów na komponenty do których zostały przypisane błędy w bugzilli stan błędów w Linuksie przedstawia się następująco:
ACPI
- 80 otwartych błędów
- 72 błędy, którymi ktoś się zajmował w ciągu ostatnich dwóch miesięcy
- 215 błędów poprawionych w tym roku
- 1595 błędów poprawionych od 2002-11-06
Platform
- 89 otwartych błędów
- 43 błędy, którymi ktoś się zajmował w ciągu ostatnich dwóch miesięcy
- 83 błędy poprawione w tym roku
- 524 błędy poprawione od 2002-11-06
Memory Management
- 53 otwartych błędów
- 23 błędy, którymi ktoś się zajmował w ciągu ostatnich dwóch miesięcy
- 38 błędów poprawionych w tym roku
- 283 błędy poprawione od 2002-11-06
Process Mgmnt
- 13 otwartych błędów
- 7 błędów, którymi ktoś się zajmował w ciągu ostatnich dwóch miesięcy
- 13 błędów poprawionych w tym roku
- 149 błędów poprawionych od 2002-11-06
I/O Storage
- 157 otwartych błędów
- 75 błędów, którymi ktoś się zajmował w ciągu ostatnich dwóch miesięcy
- 109 błędów poprawionych w tym roku
- 936 błędów poprawionych od 2002-11-06
File systems
- 136 otwartych błędów
- 51 błędów, którymi ktoś się zajmował w ciągu ostatnich dwóch miesięcy
- 89 błędów poprawionych w tym roku
- 716 błędów poprawionych od 2002-11-06
Power Management
- 62 otwartych błędów
- 31 błędów, którymi ktoś się zajmował w ciągu ostatnich dwóch miesięcy
- 28 błędów poprawionych w tym roku
- 215 błędów poprawionych od 2002-11-06
Networking
- 80 otwartych błędów
- 27 błędów, którymi ktoś się zajmował w ciągu ostatnich dwóch miesięcy
- 84 błędy poprawione w tym roku
- 597 błędów poprawionych od 2002-11-06
Drivers
- 505 otwartych błędów
- 242 błędy, którymi ktoś się zajmował w ciągu ostatnich dwóch miesięcy
- 286 błędów poprawionych w tym roku
- 2938 błędów poprawionych od 2002-11-06
SCSI
- 35 otwartych błędów
- 14 błędów, którymi ktoś się zajmował w ciągu ostatnich dwóch miesięcy
- 37 błędów poprawionych w tym roku
- 271 błędów poprawionych od 2002-11-06
DVB
- 47 otwartych błędów
- 19 błędów, którymi ktoś się zajmował w ciągu ostatnich dwóch miesięcy
- 18 błędów poprawionych w tym roku
- 82 błędów poprawionych od 2002-11-06
Timers
- 10 otwartych błędów
- 7 błędów, którymi ktoś się zajmował w ciągu ostatnich dwóch miesięcy
- 9 błędów poprawionych w tym roku
- 98 błędów poprawionych od 2002-11-06
Inne komponenty
- 71 otwartych błędów
- 29 błędów, którymi ktoś się zajmował w ciągu ostatnich dwóch miesięcy
- 54 błędy poprawione w tym roku
- 671 błędów poprawionych od 2002-11-06
Od 2002-11-06
- 1349 otwartych błędów, 211 zostało policzonych jako regresje
- 353 błędy, którymi ktoś się zajmował w ciągu ostatniego miesiąca
- 644 błędy, którymi ktoś się zajmował w ciągu ostatnich dwóch miesięcy
- 10598 otwartych błędów od 2002-11-06
- 4056 zostało odrzuconych
- 2336 nie da się odtworzyć lub dane są niekompletne
- 1375 oznaczonych jako niewłaściwe
To oczywiście tylko część błędów znajdowanych w jądrze, niektóre nie trafiają do bugzilli, tylko bezpośrednio na LKML i listy związane z danym podsystemem. Projekt KernelOOPS prowadzi własne statystyki błędów zgłaszanych w poszczególnych wersjach jądra systemu.
Więcej informacji: http://www.ussg.iu.edu/hypermail/linux/k.../1332.html
Znalazłeś literówkę? Zgłoś ją używając formularza!
Jeśli uważasz, że ten nius jest nieobiektywny, przedstawia nieprawdziwe wydarzenie, jest spamem lub nie spełnia standardów serwisu, napisz raport.
Niusy na podobny temat:
Komentarze są prywatnymi opiniami dodających je osób. Prosimy o zachowanie kultury wypowiedzi. Komentarze obraźliwe oraz obniżające poziom serwisu będą usuwane. Więcej w regulaminie komentowania.
65 komentarzy
Wszystkie autorskie niusy w serwisie publikowane są na licencji Creative Commons Uznanie autorstwa 2.5 Polska.
Przydałoby się słowo wyjaśnień, że tych kilka zignorowanych błędów to pewnie po prostu prośby o tak egzotyczne feature'y, że nikt się nimi nie zainteresował.
Nie wiem, czy w bugzilli są zgłaszane jakieś prośby o ficzery – z tego co kiedyś widziałem (jak się tym zajmowałem), to są tam tylko raporty błędów. Oczywiście niektóre z nich mogą być niepoprawne lub dotyczyć systemów z binarnymi sterownikami – dlatego są ignorowane.
Nie wiem jak w Linuksowej – w np. Gnomowej to powszechna praktyka.
W bugzilli Wine i Mozilli jest tak samo, więc dotyczy to raczej tej linuksowej.
w Wine to często ciężko odróżnić błąd od feature requestu. W końcu zgłoszenie w stylu "Gra x mi się wysypuje, gdy na n'tym poziomie zaatakuję bossa y" powinno być potraktowane jako błąd, ale może równie dobrze być odebrane jako feature request "dodanie obsługi gry x".
i widzicie jakie to otwarte oprogramowanie jest błędne ? A w Windows tylko kilkadziesiąt błędów, poprawionych od razu [rotfl].
Specjalnie dla ciebie poprawili bledy, ktore powodowaly ze trojany byly niestabilne.
A może Microsoft przyznaje się tylko do tych kilkudziesięciu, i to pod warunkiem, że już je poprawił?
niewątpliwie: i to jest urok zamkniętego źródła: nie wiesz co siedzi w środku, nie masz prawa zapytać i nie masz pododu aby obdarzać autora zaufaniem.
Wy się podniecacie a mi to wygląda na ironię, po prostu:)
Głupi jesteś czy głupiego udajesz? Aż mi szkoda słów na takie coś więc powiem tylko: a jaką masz gwarancję, że wszystkie błędy windowsowe znasz (zwłaszcza, że MS często bugi klasyfikuje jako "feature") i przez "od razu" masz na myśli 2-3 tygodnie dla błędów krytycznych?
Merytorycznie, zgadzam się z Tobą w 100%. Po raz kolejny muszę Ci jednak dać minusa za kulturę wypowiedzi. Rozumiem, że możesz być zirytowany poziomem czyjejś niewiedzy i ignorancji, ale uważam że powinieneś wyrażać się bardziej oględnie. Sposób wyrażania dezaprobaty w stosunku do wypowiedzi przedmówcy w stylu "Głupi jesteś czy głupiego udajesz?" nie najlepiej świadczy zarówno o Twojej kulturze, jak i inteligencji.
> Aż mi szkoda słów na takie coś więc powiem tylko: a jaką masz
> gwarancję, że wszystkie błędy windowsowe znasz
A w linuchu myslisz, ze wszystkie znasz?
Powyzsze zestawienie to lista znanych bledow, nie mniej i nie wiecej.
Po pierwsze błędy należy podzielić na 2 kategorie: luki, czyli błędy naruszające bezpieczeństwo systemu oraz poprawki usuwające problemy lub dodające nowe funkcje.
Tymi drugimi microsoft prawie w ogóle się nie zajmuje. Problemy muszą uniemożliwiać pracę, aby zostały przez MS poprawione. Rozwiązania mniej istotnych problemów i nowe funkcje otrzymasz jedynie _kupując_ nową wersję.
Zatem możemy porównywać jedynie stan luk w systemie. Jak wygląda sytuacja dla obu systemów?
Z punktu widzenia użytkownika luki w windows znaleźć jest trudno, gdyż nie masz dostępu do kodu. Mimo to są znajdowane i to dość często, powodując fale ataków różnych wirusów.
W Linuksie kod jest dostępny, każdy cracker może go przejrzeć i poszukać luk do wykorzystania, a jakoś udaje się to bardzo rzadko.
Świadczy to o tym, że Linux został już pozbawiony prostych błędów bezpieczeństwa, od których aż roi się w windows, skoro można je odnaleźć nie mając nawet dostępnego źródła.
A za co ten komentarz został "wyminusowany"? Pytam z ciekawości, bo zastanawiam się, czy to nie jest prawda, jest niezgodne z zasadami dobrego wychowania czy może jest niewygodne?
Memphis: I to i to. Wyrazanie sie "niepochlebnie" o Linuxie jest niezgodne z zasadami dobrego wychowania, to jasne;-). Niewygodne, bo jesli munk pisze farmazony typu: "Po pierwsze błędy należy podzielić na 2 kategorie: luki, czyli błędy naruszające bezpieczeństwo systemu oraz poprawki usuwające problemy lub dodające nowe funkcje.
Tymi drugimi microsoft prawie w ogóle się nie zajmuje. Problemy muszą uniemożliwiać pracę, aby zostały przez MS poprawione. Rozwiązania mniej istotnych problemów i nowe funkcje otrzymasz jedynie _kupując_ nową wersję." to tak ma byc. Nieistotne, ze to niezgodne z prawda (wystarczy zadac sobie troche trudu wejsc np. na http://www.microsoft.com/windowsxp/sp2/features.m… i sprawdzic). Jesli myslisz inaczej i odwazysz sie to powiedziec tos cymbal i cham!
czyżby koledze obce pojęcie ironii…
pozdrawiam
Następnym razem będziesz musiał, specjalnie dla nieuświadomionych, rozwinąć skrót ROTFL, bo tyle minusów dostałeś…
istotnie załamka… a może w te zielono-czerwone guziki klika się przed przeczytaniem wiadomości? sam też się co jakiś czas na tym łapię… chociaż niektórych autorów mogę "plusować" w ciemno.
OT: Bo mnie się wydaje, że brakuje trzeciego guzika spełniającego funkcję guzika czerwonego. Czyli aby było tak: +/- na zasadzie zgadzam się z komentarzem. Dodatkowo trzecia ikonka "moderacyjna", która po przekroczeniu pewnej masy krytycznej znikałaby komentarz jak to się dzieje teraz.
Wydaje mi się, że taki system byłby bardziej "user friendly".
@Jakub: to by bylo najlepsze rozwiazanie
Z tymi błędami, którymi ktoś się zajmował w ciągu ostatnich dwóch mięsięcy, to o co chodzi? Były one łatane przez dwa ostatnie miesiące, czy może zostały odkryte dwa miechy temu? W sumie raczej wychodzi te pierwsze, ale wolałbym się upewnić. I jaki jest ich status: naprawione, do naprawienia, a może obydwa?
Chodzi o to, że ktoś próbował je naprawić w ciągu ostatnich dwóch miesięcy, ale jeszcze się to nie udało.
Wiem wiem nie karmić trolla ale nie mogę się powtrzymać:)
Ekstra: A ty masz jedną wielką dżurę w móżgu:) Spadaj drogie dziecko neo na onet gdzie jest mnóstwo podobnych tobie idiotów.
p.s. Sorry za to ostatnie ale należało mu się.
i to ma być system? śmiech na sali, żal.pl
Zwróćcie uwagę na sekcje Drives, tak jak mówił Linus w sterownikach jest średnio 7 razy tyle błędów, dlatego powinno się przekompilować samemu kernel
W większości dystrybucji sterowniki (większość) są ładowane jako moduły, więc przy normalnym sprzęcie masz może 60-100 błędów.
Niekoniecznie. Jeden sterownik (tzn. moduł) może obsłużyć kilka urządzeń – szczególnie jeśli mają wspólny interfejs (np. do hosta USB są 4 czy 5 sterowników – [UEO]HCI i coś tam jeszcze). Jednak błąd może się ujawniać tylko przy np. konkretnym sprzęcie (przy USB – przy konkretnej płycie głównej?).
> Zwróćcie uwagę na sekcje Drives, tak jak mówił Linus w
> sterownikach jest średnio 7 razy tyle błędów, dlatego powinno
> się przekompilować samemu kernel
Albo przejsc ze sterownikami do userlandu jak w 3-cim minixie
To jest fajny pomysł żeby w zabezpieczonych API uruchamiać sterowniki własnościowe, żeby mogły tylko odwołać się do konkretnego sprzętu. W końcu nie wiadomo co w nich siedzi. Z drugiej strony i w otwartych by można było nieco odświeżyć API i zapakować je w sandboksy.
W tym momencie dochodzimi do mikrokernela, ze wszystkimi wadami mikrokernela.
W przypadku Linuksa dochodzi jeszcze niechec developerow kernela do stabilizacji API i ABI sterownikow.
I co, od przekompilowania znikną? Kto daje plusy takim komentarzom?
nadal uwazam, ze powinien byc jeden kernel produkcyjny bez zmian
Proponuję pobrać źródła jądra wykorzystywanego w RHEL lub SLES i wrzucić łatki. Jądra enterpriseowych dystrybucji mają długi czas wsparcia technicznego.
I co z tego, że są błędy. Każde oprogramowanie je ma – niezależnie czy otwarte, czy zamknięte. Niektórzy chyba myślą, że w firmach (np. Microsofcie) programiści to debile, którzy nie potrafią nic napisać, a programiści softu open source to sami bogowie kodu.
> Niektórzy chyba myślą, że w firmach (np. Microsofcie) programiści
> to debile, którzy nie potrafią nic napisać, a programiści softu
> open source to sami bogowie kodu.
No niektorzy najwyrazniej tak wlasnie mysla…
bo tak jest – podpisano: bog kodu.
pozwolę sobie przytoczyć słowa z jednego z poradników do rekompilacji kernela
"Kernel, który dany jest nam w dystrybucji posiada mnóstwo zbędnych rzeczy, a przez to jest duży. Jądro własnej kompilacji jest dostosowane do naszego sprzętu, jest mniejsze, a co za tym idzie może być bardziej stabilniejsze.
"
"Bardziej stabilniejsze", powiadasz? Bardziej stabilne.
A czy raport ten mówi o całej masie zbędnego badziewa, które znajduje się w jądrze? Nie wydaje mi się aby obecność reliktów wpływała na jego stabilność, a o wydajności już nie wspominając..
Konkretnie ?
@scapegoat
To jest tak. Zgłoś do nich, ze coś jest niepotrzebnym syfem. Jeśli nie znajdą się żadni ludzie używający np. danego sterownika to go wyrzucą. Jeśli znajdzie się choć parę osoób (a z tego co widziałem wystarczy choć jedna, która weźmie na swoje barki opieke nam tym sterownikiem) to zostanie on dalej w kernelu. Ale skoro znajdzie się ktoś kto go używa to nie jest zbędnym badziewiem.
@agent_J – tu nie chodzi o to ze "łosie" pracuja dla mikroshita – tylko chodzi o to ze tutaj nie tylko masz zestawienie 'wszystkich' odkrytych bledow – ale i caly kod zrodlowy – jak jestes "programista" to se sam mozesz przeanalizowac kod i go poprawic – a w winshicie ewentualnie mozesz se pulpit zmienic…
Spoko. Tylko ilu użytkowników to programiści? Dla tej części otwarty kod, to zaleta. Ja tego kodu nie rozumiem, więc nie robi mi to różnicy.
Dzięki temu masz pewność, że nie ma tam żadnego malware itp., każdy praktycznie element systemu można zmienić (np. zainstalować GNOME zamiast KDE). Nawet jeżeli ty nie rozumiesz kodu, to możesz zgłaszać pomysły, a programiści zajmą się jego realizacją, jeżeli te pomysły będą dobre. Ty także czerpiesz z tego, że inni zgłaszają swoje pomysły ulepszając oprogramowanie. M$ musi starać się wstrzelić w potrzeby klientów, w open source dzieje się to naturalnie.
> M$ musi starać się wstrzelić w potrzeby klientów,
> w open source dzieje się to naturalnie.
Dobre podsumowanie. Dlatego to produkty MS sa dla zwyklych
uzytkownikow duzo bardziej uzywalne, bo MS musi a open source nie…
Myślę, że wcale nie dla tego są bardziej używalne tylko dla tego, że Windows od pierwszych wersji miał być systemem dla ZU natomiast Linux takim systemem jest od bardzo niedawna (a i już teraz w wielu sprawach bije windowsa, którego siłą są jedynie aplikacje oraz sterowniki pisane przez zewnętrzne firmy)
Problem jest taki, że wolne oprogramowanie jest używane głównie przez ludzi którzy komputerami interesują się trochę bardziej, niż na tyle ile muszą, żeby na przykład coś napisać. Dlatego pomysły i potrzeby takich ludzi jak ja, hakerzy zwykle mają gdzieś, bo dla nich są zwyczajnie głupi i bezużyteczne. Nie mam pewności, że nie ma malware, bo ja tego nie sprawdzę. To że Ty sprawdzisz i mi powiesz jest równie wiarygodne, jak to że choćby Microsoft mi powie, że nie ma malware (czyli bardzo prawdopodobne). A syfiastych programików o których pochodzeniu nie wiadomo nie instaluję nie zależnie od tego, czy są otwarte czy zamknięte. Nie wiem czy wiesz, ale w takich firmach jak Microsoft oni nie "strzelają" od tak sobie, żeby wiedzieć czego oczekują klienci. Zatrudnia się armię osób (często antropologów kultury), którzy to badają (przez wyjście do potencjalnych klientów). Plus jest taki, że oni nie nazwą mnie lamą albo idiotą, bo nie zrozumiem części Stallmanowskiej ideologii, zależności prawnych, itd. Istotne jest jeszcze to, o czym wspomniał jarek.
@Memphis:
Jeśli sprawdza kod iluśtam programistów – niezależnych – to zawsze jest większa szansa na brak ukrytego oprogramowania jak gdy kod sprawdza tylko jedna "osoba" – MS. Poza tym OS może sprawdzić każdy i jak coś znajdzie i opublikuje to firma/program straci wiarygodność i użytkowników a znalezienie czegoś takiego jest prostsze gdy masz dostępny kod
-
Co do potrzeb, to Linux *był* dla ludzi zainteresowanych komputerami. Teraz się to zmienia. Wkładam/podłączam do laptopa kartę pamięci/pendrive'a/aparat fotograficzny i system sam go znajduje, informuje mnie o tym i proponuje np zgranie zdjęć czy odtwarzanie muzyki. W windowsie, pomimo oficjalnego wsparcia producenta laptopa, karta pamięci się nie otwiera. Pewnie brakuje sterownika albo coś, ale ja NIE MUSZĘ o tym wiedzieć.
Chcę nagrać swoje mp3 na płytę CD-Audio. Co robię? Wkładam płytę, klikam "nagraj płytę CD-Audio" wybieram pliki i nagrywam. W windowsie szukam godzinami czegoś w necie i w końcu dowieduję się, że potrzebuję jakiś program (płatny oczywiście).
-
-
Podaj, proszę, przykład gdzie windows jest przyjaźniejszy od Linuksa – pomijając obsługę niestandardowego sprzętu, bo to wszyscy wiemy, że jest problemem
Z Windowsami jest taki problem ze jezeli chcesz aby wszystko ci dzialalo musisz robic to w 100% zgodnie z zaleceniami producentow sprzetu i oprogramowania. Jak masz inna wersje jezykowa systemu albo jakiegos programu juz pojawiaja sie problemy (np. chcialem wgrac firmware do odtwarzacza mp3 Sony ale mialem polska wersje windowsa i niestety nie dalo rady). Czyli najlepiej nie sciagac darmowych/platnych aplikacji ktore nie maja znaczka microsoftu. Cos zainstalujesz po swojemu (inna paczka kodekow niz te od microsoftu) i juz cos tam potem nie chce dzialac. I tak w kolo…
@Plum: Pewnie nie wiesz, ale jesli jakis programista ma potrzebe zerknac w kod Windows, to moze. Microsoft od dluzszego czasu kod zrodlowy udostepnia.
IMHO od wersji 2.6.27 powinni bardziej skupić się na poprawianiu tych błędów, a dodawanie nowych funkcji przesunąć na drugie miejsce. Zwłaszcza, że poprawienie niektórych z nich mogłoby doprowadzić do większej stabilności i używalności jądra…
Problem z błędami wygląda w telegraficznym skrócie tak:
1) jest mało wykwalifikowanych testerów
a) potrafiących dobrze opisać co jest nie tak
b) potrafiących dobrze testować jądro
c) potrafiących dobrze przetestować otrzymane łatki
2) jest mało deweloperów, którzy chcą poprawiać błędy
a) jeśli raport jest źle napisany a zgłaszający błąd nie potrafi opisać co jest nie tak, to bardzo często jest ignorowany
b) deweloper bardzo często nie może u siebie odtworzyć błędu, dlatego potrzebuje pomocy ze strony testera
c) deweloper otrzymuje pensje za napisane ficzery a nie poprawianie błędów występujących u 1% użytkowników jego kodu
Próbowałem kiedyś poprawić punkt pierwszy, ale nic z tego nie wyszło. Wiesz dlaczego? Bo tak na prawdę mało ludzi dba o to, żeby testować system. (Jeśli jednak chcesz pomóc deweloperom, to możesz zacząć od lektury www dot stardust dot webpages dot pl slash files slash handbook slash handbook-en-0.3-rc1.pdf)
Thnx za manual.
IMO od wersji 2.6.27 powinni się skupić nad takim zaprojektowaniem jądra żeby zmniejszyć szanse powstania błędów.
A poza tym:
-nowy system uprawnień (tak jak w Windows – dziedziczenie i możliwość ustawienia kilkunastu uprawnień dla każdego użytkownika z osobna)
-przeniesienie obsługi sprzętu graficznego z X.org do jądra
"IMO od wersji 2.6.27 powinni się skupić nad takim zaprojektowaniem jądra żeby zmniejszyć szanse powstania błędów."
Eghm… chyba nie rozumiesz przyczyn powstawania błędów – w którymś numerze Dragonia Magazine jest krótki esej na ten temat.
"nowy system uprawnień"
Zainteresuj się SELinuksem.
"przeniesienie obsługi sprzętu graficznego z X.org do jądra"
Jeśli chodzi o modeset, to jestem całkowicie za
"Zainteresuj się SELinuksem."
SELinux nie ma graficznego edytora
A w każdym razie nie w środowisku graficznym
"Eghm… chyba nie rozumiesz przyczyn powstawania błędów – w którymś numerze Dragonia Magazine jest krótki esej na ten temat."
To może od drugiej strony – tak żeby ewentualne błędy miały jak najmniejszy zasięg i były trudne do wykorzystania przy atakach.
"SELinux nie ma graficznego edytora
A w każdym razie nie w środowisku graficznym"
W systemie mam kilka narzędzi do zarządzania SELinuksem, politykami, tworzenia nowych polityk etc. To już nie jest epoka kamienia łupanego jak podczas mojego pierwszego spotkania z SEL – w okolicach jakiegoś Red Hat 7.x. Zajrzyj od czasu do czasu na selinuxnews dot org – tam deweloperzy informują o takich nowinkach
.
"tak żeby ewentualne błędy miały jak najmniejszy zasięg"
Teoretycznie mikrojądro by mogło tutaj coś wnieść, ale:
- to nie zmienia faktu, że błąd występuje – co z tego, że system się nie wywali jak sterownik kontrolera SCSI poszedł się paść? – już wolę, żeby system się szybko wywalał
- mikrokernel to słowo wywołujące flejmy na lkml
" i były trudne do wykorzystania przy atakach."
Błędy bezpieczeństwa, to kropla w morzu innych błędów. Powiedzmy, że stackprotector załatwia część problemów.
Osobiście używam 2.6.24-rc6 na ruterze i nigdy nie było żadnych problemów (raz tylko nfs nie chciał wstać ale restart pomógł:)) oraz znam pewien serwer w pewnej firmie który stoi od dawien dawna na 2.4.x (x bo nie pamiętam dokładnie ale dość niska liczba np 16) i nie przypominam sobie żeby były problemy z stabilnością.
Od czasu do czasu przeglądam changelog'i i tam sprawa wygląda podobnie.
Troche tego jest….
Znalazl ktos raport porownojacy bugi w kodzie BSD vs Linuxa?
Tyle sie zawsze mowilo o wyzszosci daemona nad Tuxem ( min. Teo ), tylko nie widzialem nigdy zadnego porownania…
Upps literowka, oczywiscie mam na mysli wypowiedzi Theo de Raadt-a
scan dot coverity dot com/rung1.html
Fixed Verified Uninspected Defects / KLOC
FreeBSD 0 6 605 0.386
NetBSD 1316 196 1405 0.335
Linux-2.6 452 48 413 0.127
O, pare newsow temu gdy ktos mi zamachal przed oczami haslem
o rzekomej superjakosci kodu w BSD poprosilem o zestawienie
tego z objetoscia kodu (ostatnia kolumna w powyzszym).
Dodatkowo zawsze warto w takiej sytuacji uwzglednic
ilosc ludzi ktorzy dlubia w nim. Wiadomo, im wiecej osob
przeglada kod (w roznym celu), tym wiecej syfu wyjdzie na
swiatlo dzienne. I nie oszukujmy sie, ilosc ludzi przegladajacych
kod linucha jest duzo wieksza niz BSD.
Geez, bylo tyle razy walkowane. Coverity zapomnialo, ze FreeBSD ma wykupiony – od nich – wlasny skaner i poprawiane bledy sa "odznaczane" tam, a nie na maszynie Coverity. W zwiazku z tym poprawek we FreeBSD po prostu nie policzyli.
"FreeBSD is unique, in that they have been a Coverity user since before the Scan project started, and their analysis is run outside of the Scan framework. The Scan statistics for FreeBSD have not been pulling in the numbers from that work, though it has been on my to-do list to fix that for some time."
http://scan.coverity.com/