🚀 go-pugleaf

Nie wyraziłem się dosyć jasno.
Akurat z przetłumaczeniem sobie poradziłem ;), chodziło mi raczej o
filozofię takiego postępowania. Szczegóły poniżej. 

> [*] Pytaj o rozwojowe i/lub niekompletne kody/sterowniki

IMO moglo by to się nazywać:
[*] Unstabling kernel, using untested and/or uncompleted features


> No dobrze. Jest tak, że gdy kernel ma określoną funkcjonalość jest
> uważany za stabilny. Ale stabilny oznacza też najczęściej
> przestarzały.

Do tego zmierzam. Jaki procent użytkowników nie zaznacza omawianej opcji
przy konfiguracji jądra ?
Innymi słowy, wielu użytkowników w zasadzie używają stabilnej wersji jądra 
(a jakże 2.4.x), ale równocześnie używają wynalazków nie-do-końca 
wytestowanych, czy nawet nie-do-końca napisanych.
Uważam że dobrym pomysłem byłoby pozostawnienie tej całej funkcjonalności
w gałęzi 2.3.x (2.1.x; 2.5.x; itd.) i usunięcie jej ze ,,stabilnych''
wersji.

> Dlatego też możesz sobie włączyć kod/sterowniki które
> pewnie będą pełnić przypisaną im funkcję ale robisz to na własne
 ~~~~~~~~
> ryzyko (de facto i tak cały kernel używasz na własne ryzyko ale to już
> inna inszość).

Pewnie tak. I wogóle całego linuksa używam na własne ryzyko (a jakiego
systemu nie?). Bo pewnie będzie działał, ale czy będzie działał pewnie?

Piszę to wszystko dlatego, że co jakiś czas spotykam się z reakcjami
różnych użytkowników, którzy włączają na masę różnych dodatków, 4
patchów, i 10 patchów na patche, żeby to wszystko dało się skompilować.
Później im się to wysypuje; dzowonią, piszą, spać nie dają, krzyczą 
jaki ten Linux jest do dupy, bo ,,nie działa'' mimo że używają stabilnej
wersji -- i weź im za każdym razem tłumacz.

Uważam, że podczas zaznaczania jakiejś niewytestowanej funkcjonalności,
zakładania patchy, etc, powinno być jasno i wyraźnie napisane, że możemy
się liczć z jakąś niestablilnością. 
A najlepiej żeby po jakimś patchowaniu uname -r pokazywał jakieś 
2.4.22-UNSTABLE.

-- 
Pozdrawiam
Grzegorz Bajson