Krótki raport o stanie błędów w jądrze Linux

4 maja 2008

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.

PODOBNE WPISY:

żadnych reklam, sama wiedza.

Zarejestruj się na BEZPŁATNY NEWSLETTER i raz w tygodniu otrzymuj najważniejsze wiadmości
ze świata IT, nowych technologii i kryptowalut.

Bez reklam.

Zarejestruj się za darmo

Technologie

Deathplanter

4 maja 2008

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ł.

Odpowiedz
1. optimizationkit
  
  4 maja 2008
  
  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.
  
  Odpowiedz
  1. uzytkownik
    
    4 maja 2008
    
    Nie wiem jak w Linuksowej – w np. Gnomowej to powszechna praktyka.
    
    Odpowiedz
    1. diablownik
      
      4 maja 2008
      
      W bugzilli Wine i Mozilli jest tak samo, więc dotyczy to raczej tej linuksowej.
      
      Odpowiedz
    2. Maciek
      
      5 maja 2008
      
      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".
      
      Odpowiedz
Maciek

4 maja 2008

i widzicie jakie to otwarte oprogramowanie jest błędne ? A w Windows tylko kilkadziesiąt błędów, poprawionych od razu [rotfl].

Odpowiedz
1. Michal
  
  4 maja 2008
  
  Specjalnie dla ciebie poprawili bledy, ktore powodowaly ze trojany byly niestabilne.
  
  Odpowiedz
2. tuxmaniak
  
  4 maja 2008
  
  A może Microsoft przyznaje się tylko do tych kilkudziesięciu, i to pod warunkiem, że już je poprawił?
  
  Odpowiedz
  1. Maciek
    
    4 maja 2008
    
    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.
    
    Odpowiedz
  2. much
    
    4 maja 2008
    
    Wy się podniecacie a mi to wygląda na ironię, po prostu:)
    
    Odpowiedz
3. niedzwiedz_2
  
  4 maja 2008
  
  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?
  
  Odpowiedz
  1. Jarek
    
    4 maja 2008
    
    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.
    
    Odpowiedz
  2. jarek
    
    4 maja 2008
    
    > 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.
    
    Odpowiedz
    1. munk
      
      4 maja 2008
      
      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.
      
      Odpowiedz
    2. Memphis
      
      4 maja 2008
      
      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?
      
      Odpowiedz
    3. Ku8a
      
      5 maja 2008
      
      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!
      
      Odpowiedz
  3. Maciej Mrozowski
    
    4 maja 2008
    
    czyżby koledze obce pojęcie ironii…
    pozdrawiam
    
    Odpowiedz
4. mcv
  
  4 maja 2008
  
  Następnym razem będziesz musiał, specjalnie dla nieuświadomionych, rozwinąć skrót ROTFL, bo tyle minusów dostałeś… 😉
  
  Odpowiedz
  1. Maciek
    
    5 maja 2008
    
    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.
    
    Odpowiedz
    1. Jakub Klawiter
      
      5 maja 2008
      
      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".
      
      Odpowiedz
    2. Michal
      
      5 maja 2008
      
      @Jakub: to by bylo najlepsze rozwiazanie
      
      Odpowiedz
http://nintyfan.open

4 maja 2008

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?

Odpowiedz
1. optimizationkit
  
  4 maja 2008
  
  Chodzi o to, że ktoś próbował je naprawić w ciągu ostatnich dwóch miesięcy, ale jeszcze się to nie udało.
  
  Odpowiedz
2M1R

4 maja 2008

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ę.

Odpowiedz
working man

4 maja 2008

i to ma być system? śmiech na sali, żal.pl

Odpowiedz
revcorey

4 maja 2008

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

Odpowiedz
1. abc
  
  4 maja 2008
  
  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.
  
  Odpowiedz
  1. uzytkownik
    
    4 maja 2008
    
    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?).
    
    Odpowiedz
2. jarek
  
  4 maja 2008
  
  > 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 🙂
  
  Odpowiedz
  1. abc
    
    4 maja 2008
    
    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.
    
    Odpowiedz
    1. trasz
      
      9 maja 2008
      
      W tym momencie dochodzimi do mikrokernela, ze wszystkimi wadami mikrokernela.
      
      W przypadku Linuksa dochodzi jeszcze niechec developerow kernela do stabilizacji API i ABI sterownikow.
      
      Odpowiedz
3. arag0rn
  
  4 maja 2008
  
  I co, od przekompilowania znikną? Kto daje plusy takim komentarzom?
  
  Odpowiedz
Gf

4 maja 2008

nadal uwazam, ze powinien byc jeden kernel produkcyjny bez zmian

Odpowiedz
1. optimizationkit
  
  4 maja 2008
  
  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.
  
  Odpowiedz
agent_J

4 maja 2008

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.

Odpowiedz
1. jarek
  
  4 maja 2008
  
  > 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…
  
  Odpowiedz
  1. Maciek
    
    5 maja 2008
    
    bo tak jest – podpisano: bog kodu.
    
    Odpowiedz
  2. revcorey
    
    5 maja 2008
    
    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.
    
    "
    
    Odpowiedz
    1. mdh160
      
      6 maja 2008
      
      "Bardziej stabilniejsze", powiadasz? Bardziej stabilne.
      
      Odpowiedz
scapegoat

4 maja 2008

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..

Odpowiedz
1. Maciej Grela
  
  4 maja 2008
  
  Konkretnie ?
  
  Odpowiedz
2. blah
  
  4 maja 2008
  
  @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.
  
  Odpowiedz
PLum

4 maja 2008

@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…

Odpowiedz
1. Memphis
  
  4 maja 2008
  
  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.
  
  Odpowiedz
  1. Jolly Roger
    
    5 maja 2008
    
    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.
    
    Odpowiedz
    1. jarek
      
      5 maja 2008
      
      > 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…
      
      Odpowiedz
    2. niedzwiedz_2
      
      5 maja 2008
      
      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)
      
      Odpowiedz
    3. Memphis
      
      5 maja 2008
      
      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.
      
      Odpowiedz
    4. niedzwiedz niezalogo
      
      5 maja 2008
      
      @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 😉
      
      Odpowiedz
    5. zumek
      
      8 maja 2008
      
      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…
      
      Odpowiedz
2. trasz
  
  9 maja 2008
  
  @Plum: Pewnie nie wiesz, ale jesli jakis programista ma potrzebe zerknac w kod Windows, to moze. Microsoft od dluzszego czasu kod zrodlowy udostepnia.
  
  Odpowiedz
diablownik

4 maja 2008

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…

Odpowiedz
1. optimizationkit
  
  4 maja 2008
  
  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)
  
  Odpowiedz
  1. LM
    
    5 maja 2008
    
    Thnx za manual.
    
    Odpowiedz
2. abc
  
  4 maja 2008
  
  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
  
  Odpowiedz
  1. optimizationkit
    
    4 maja 2008
    
    "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 🙂
    
    Odpowiedz
    1. abc
      
      4 maja 2008
      
      "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.
      
      Odpowiedz
    2. optimizationkit
      
      5 maja 2008
      
      "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.
      
      Odpowiedz
3. norbert_ramzes
  
  5 maja 2008
  
  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.
  
  Odpowiedz
SuperDaemon

5 maja 2008

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…

Odpowiedz
1. SuperDaemon
  
  5 maja 2008
  
  Upps literowka, oczywiscie mam na mysli wypowiedzi Theo de Raadt-a
  
  Odpowiedz
2. optimizationkit
  
  5 maja 2008
  
  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
  
  Odpowiedz
  1. jarek
    
    5 maja 2008
    
    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.
    
    Odpowiedz
  2. trasz na wyjezdzie
    
    8 maja 2008
    
    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/
    
    Odpowiedz