X bez roota!
- Dodano: 12 May 2008
- Wprowadził: optimizationkit
- Komentarze: 77
Dave Airlie pochwalił się rezultatami swojej pracy przy zmniejszaniu uprawnień serwera X. Problem polega na tym, że serwer X na Linuksie działa z uprawnieniami administratora – tak wysokie uprawnienia są mu potrzebne między innymi do zmiany ustawień karty graficznej, jednak negatywnie wpływają na bezpieczeństwo systemu.
Sytuacja zmieniła się, gdy Dave przeniósł wykrywanie/zmianę ustawień karty graficznej do jądra systemu. Dzięki kilku dodatkowym poprawkom udało mu się uruchomić serwer X działający bez uprawnień roota.
(..) Mogę uruchomić serwer + gnome-session + DRI2 + compiz + glxgears na sześcianie. Wprawdzie w krótkim czasie dostaje oops’a, ale to pokazuje, że jesteśmy bardzo blisko zrealizowania marzenia.
Niestety przynajmniej na razie ta funkcjonalność jest dostępna tylko dla posiadaczy kart graficznych Intela obsługiwanych przez modesetting w jądrze systemu. Możemy mieć nadzieję, że już wkrótce modesetting zostanie udostępniony również dla sterowników nouveau oraz radeonhd.
Więcej informacji: http://airlied.livejournal.com/59521.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.
77 komentarzy
Wszystkie autorskie niusy w serwisie publikowane są na licencji Creative Commons Uznanie autorstwa 2.5 Polska.
BTW.
W komentarzu pod artykułem Daniela o modesetting przewidziałem taki rozwój wypadków, ale nie sądziłem, że Dave tak szybko się za to zabierze
…Noveau? To w ogole ktokolwiek z tego juz korzysta?
Tak czy siak, milo, ze ktos wreszcie sie wzial za przenoszenie Xorg'a do userspace. Szkoda tylko, przy aktualnym tempie wydawania wersji stabilnych mozemy sie spodziewac chociazby RC za jakies… pol roku? 
Ciekawi mnie tez, ile bedzie trwalo pisanie stabilnych latek na kernel.
nouveau nie jest jeszcze "uzywalnym" – wstrzymaj sie wiec z takimi opiniami.
Z tego co slyszalem, nawala glownie czesc 3D… Sorki za literowke, mialo byc oczywiscie NoUveau. A co do RC – mowilem o Release Candidate dla Xorg'a, a nie opensourcowych sterownikow…
PS:
Tak, wiem, o to sie nie pyta, ale mozesz mi wprost napisac za co minus?
pyta, pyta – bo dzieki temu mozna sie czegos na przyszlosc nauczyc
za "…Noveau? To w ogole ktokolwiek z tego juz korzysta?" – czyli wysmiewanie sie.
za "Szkoda tylko, przy aktualnym tempie wydawania wersji stabilnych mozemy sie spodziewac chociazby RC za jakies… pol roku" – czyli wysmiewanie sie.
za "Ciekawi mnie tez, ile bedzie trwalo pisanie stabilnych latek na kernel" – za bezsensowne pytanie.
co do literowki – zdaza sie
tez sie na tej nazwie nie raz mylilem 
co do stabilnych latek – przydala by sie odpowiedz naszego kochanego trolla, ale pewnie by brzmiala: wieki, a to za sprawa zlej kontroli kodu wchodzacego do jadra, tudziez "modelu jego rozwoju".
Jezu jaki Ty przeczulony jesteś. Byle krytyka a nawet zwykłe stwierdzenie faktu a Ty już w rękaw łzy wycierasz? Panuj, bo Ci pikawa strzeli. Jest jak jest, stery opensourcowe są niegotowe i hgw kiedy będą, zmiany w xorg też nie wiadomo kiedy wprowadzą, na co tu się obrażać?
Pawle: do kogo to pisales?
do mnie chyba nie, bo sie nie obrazam bez powodu, a i krytyki jakos u deathplanetera nie widze
btw. chuj pisze sie przez ch
Nie udawaj głupiego. Paweł odnosił się do Twojej zakompleksionej wiadomości. Że w ogóle chciało ci się atakować Deathplanter'a i dziubać taki długi post z cytatami… nuda, aż wychodzi uszami.
Chyba zdarza się a nie zdaża:)
Pozdrawiam!
"Ciekawi mnie tez, ile bedzie trwalo pisanie stabilnych latek na kernel."
Modesetting dla kart Intela prawdopodobnie znajdzie się w 2.6.27 – już teraz jest intensywnie testowany przez użytkowników Fedory. Jeśli chodzi o inne karty, to najlepiej zapytaj Davea.
A jak wyglada sprawa z NVidia?
Jak się czegoś dowiem, to na pewno napiszę.
Nvidia jest zazwyczaj dość skryta na temat funkcjonalności które chcą dodać w następnych sterownikach. A jako że wydają je bardzo nieregularnie to jest to jedna wielka niewiadoma.
Xorg w większości działa w userspace, tylko driver kart są w kernelspace. Problem jest w pełnym uruchomieniu Xorg'a na prawach nie root.
"tylko driver kart są w kernelspace"
Sterowniki też są w przestrzeni użytkownika – te dostarczane wraz z X.org wykorzystują interfejsy dostępne w jądrze systemu. Sterowniki zamknięte np. Nvidii są dostarczane razem z modułami do jądra pozwalającymi na obsługę AGP (pewnie PCI Express na nowszych kartach) – sam sterownik jest w przestrzeni użytkownika.
Teraz (przynajmniej dla kart Intela) będzie wyglądało to tak, że część sterownika jest w jądrze systemu – wymagający wyższych uprawnień m.in. modesetting – a część nie wymagająca wysokich uprawnień będzie w przestrzeni użytkownika.
Deathplanter: A kiedy chciałbyś to dostać? Jutro? To byś płakał, że się wywala…
Jeśli już to narzekał, nie płakał. Płakać mogą co najwyżej geecy, których życie na tym się opiera ale cóż – "każdy mierzy ludzi własną miarą".
Pewnie za linuksiarskie pół roku
Ja tam nadal czeka aż mi naprawią acpi w laptopie, które działało rok temu.
zgłaszałeś to gdzieś ? bo jeśli nie to skąd developerzy jądra mają wiedzieć, że Ci się ACPI wywala ?
Chlopie, wiesz co to userspace ? Wlasnie sporo z tego co bylo w przestrzeni uzytkownika jest przenoszone do kernela(jak chocby wpsomniane modesettings, oraz ma byc przeniesione sporo kodu z DRM), ale kompletnie nie jest to zwiazane z tym ze iksy sa odpalane z uprzywilejowanego konta
DRM jest tą częścią DRI, która od początku była w kernelu.
Chodzi Ci pewnie o prace nad DRI2 i TTM?
"Tak czy siak, milo, ze ktos wreszcie sie wzial za przenoszenie Xorg’a do userspace."
Xorg zawsze byl w userspace…
W przestrzeni jadra byla obsluga DRI oraz sterownik karty graficznej, ale nie same X'y.
A kiedy takie coś znajdzie się w FreeBSD i Solarisie? Tam FB to porażka.
A co ma framebuffer wspólnego z Xorgiem? Wyjaśnij bo nie rozumiem związku.
framebuffer to pojecie techniczne, a nie tylko nazwa sterownikow konsoli pod linuksem. co wiecej – michuk2 nawet nie odnosil sie do linuksowych kernelowych sterownikow framebuffer.
btw. zajrzyj do /usr/lib/xorg/modules – masz tam wlasnie obsluge m.in. framebuffer z Xorg – moze to jest to czego nie rozumiesz?
Możliwe, niby wiedziałem że można użyć fbdev jako sterownika grafiki do Xorga ale jakoś mnie to nei przekonuje, bo wydajność fbdev pozostawia wiele do życzenia, dlatego uznałem że nie o to mu chodziło…
Można conajwyżej filmy w mplayerze na fbdev oglądać
A patrzyles sie moze kiedys do logow Xorga ? Jedynym sposobem akecelracji 2D w iksach na kartach sisa, jest zakadowanie sisfb(i bynajmniej sie nie korzysta z iksowego modulu fbdev), bez tego zapomnij o dosboxie, zwykle sterowniki korzystaja albo z vesafb, albo soecyficznego sterownika dla karty. Wpisz sobie `modrobe -l | grep fb` by zobaczyc jakie moduly fb posiada twoje jajko, i `lsmod | grep fb`, by zobaczyc zaladowane.
morsik – przeczytaj ponownie moj komentarz – linuksowy fbdev nie jest jedynym sterownikiem w ktorym uzywa sie pojecia framebuffer. to ze przypadkiem Xorg rowniez dziala na linuksowym fbdev, nie oznacza ze inne sterowniki xorg nie maja obslugi framebuffera, polskiego bufora ramki. wrecz przeciwnie – kazdy sterownik (procz majacych "pod spodem" opengl) bezposrednio dzialajacy na sprzecie – MUSI miec obsluge framebuffer, choc nie jest to fbdev…
@michuk2: We FreeBSD ciezko powiedziec, ale Solaris mial to – w sensie, drivery w kernelu i xserwer dzialajacy na prawach uzytkownika – zanim zaczal sie nazywac Solaris. W sensie, bylo juz w SunOS 4, pietnascie lat temu.
Moze w wersji pecetowej Solarisa tego nie ma. Kwestia driverow.
Może dołożymy do życzeń modesetting dla sterownika radeon?
jeszcze nouveau, nvidia, radeonhd i inne?
mają to stopniowo implementować; na początku ma być (jest) Intel a potem Ati.
nvidia? gdzie wyczytales ze maja to stopniowo implementowac?
nigdzie nie wyczytałem… widzisz takie ":P" na końcu zdania? to znaczy że to było ironiczne akurat…
Ale swoją drogą to czemu niby mieliby nie wesprzeć nvidia?
A że to ma być stopniowo pisze tutaj: http://osnews.pl/tryby-graficzne-w-jadrze-pierwsz…
Ja jestem zadowolony z jakości sterów nvidia i uważam, że – chociaż zamknięte – są rozwijane porządnie (niewiele zamkniętego oprogramowania działa w systemach linuksowych tak dobrze). I pewnie jak ta technologia na dobre wejdzie do powszechnego użycia dla Intelów, można się spodziewać że po pewnym czasie Nvidia zareaguje i stworzy sterowniki z taką funkcjonalnością. I – bez obrazy dla szybkości rozwoju wolnego oprogramowania – sądzę że stanie się to szybciej niż stabiliczacja nouveau.
"sądzę że stanie się to szybciej niż stabiliczacja nouveau."
Ja myślę, że nikt się nie obraża. Nouveau rozwija się wolno, bo nie mają dokumentacji chipów – ot co. Deweloperzy rozwijający sterowniki dla Nvidii są w innej sytuacji – mają pełną dokumentację wszystkich układów, mają praktycznie nieograniczony dostęp do sprzętu.
…a ja pamiętam, jak tu na mnie niejaki "Memphis" naskoczył, że się czepiam o zaprzestanie rozwijania sterów dla GeForce4. Że niby "po co". Że niby: "mam przecież sterowniki – i czego mi jeszcze trzeba".
Otóż z kernelem 2.6.25 to już się tego zainstalować nie da – co przewidywałem wcześniej, że w końcu kiedyś tak się stanie, chociaż nie sądziłem, że zaledwie parę miesięcy po tym, kiedy to napisałem.
którą wersje próbowałeś zainstalować ?
To NVIDIA musi wspierać tę technologię. Poza tym nie mam wiedzy żeby powiedzieć, czy sterownik od modesettingu może być ładownym modułem. Jeśli nie, to NVIDIA musiałaby tę część kodu otworzyć i dorzucić do kernela. Idąc tą drogą nie wiadomo czy kod zostałby przyjęty jako służący zamniętemu sterowkowi…
kocio napisał to już w kwietniu.
"Idąc tą drogą nie wiadomo czy kod zostałby przyjęty jako służący zamniętemu sterowkowi…"
Nie zostałby przyjęty – kiedyś Torvalds jasno napisał co sądzi o takich hookach dla binarnych sterowników.
Inaczej by wyglądała sytuacja, gdyby Nvidia chciała wykorzystać interfejs stworzony dla otwartych sterowników nouveau – ale to chyba by było niezgodne z licencją Linuksa (przynajmniej jeśli dobrze rozumiem zapisy o łączeniu kodu na GPL z kodem nie na GPL – nie jestem prawnikiem i nie ukrywam, że bełkot licencyjny jest dla mnie mało zrozumiały.).
Ma się rozumieć, że ostatnią, która chciała mieć cokolwiek wspólnego z GeForce4: 9631.
Niestety, nie chce już "współpracować" ze źródłami nowego kernela. O ile dobrze sobie przypominam, to już 2.6.24 jej nie podchodził.
NVidia sprzedała kartę, zamknięty sterownik olała, źródeł nie wypuści – a użytkownik… niech sobie kupi nową.
A kupi, kupi – ale nie u NVidii.
A mnie ktoś tu kiedyś wciskał, że do sterowników dołączane są jakieś wrappery czy inne cosie i że nawet riva tnt2 będzie działać z najnowszymi kernelami. Czyli dupa? -.
Ja nie znam metody na instalację sterowników 9631 z kernelem 2.6.25 (a o wcześniejszych to nawet nie wspominam). O żadnych "wrapperach" – przyznaję – nic nie słyszałem.
Z wcześniejszymi kernelami (bodajże do 2.6.23 włącznie) jeszcze chciało się toto jakoś "integrować" – ale teraz już nie.
Na 2.6.24 jeszcze te stery działają, wiem z doświadczenia.
pod debianem: m-a a-i nvidia-kernel-legacy
pod 2.6.24 dziala na 100%, pod nowszym pewnie wieczorem sprawdze, ale na 95% dziala.
Mam Debiana SID (kernel 2.6.24)
GeForce 4 MX 440 8x 64bit 64MB DDR
i działa na driverach 96xx
Jeszcze nie sprawdzałem 2.6.25
…a ja mam Etcha, i żebym się ze… powiedzmy: "żebym kupę zrobił", to one się i tak nie skompilują, i już. Zgłaszają jakieś błędy.
A kompilowałem je przecież wielokronie (20 razy? 30 razy? Sam już nie pamiętam) na poprzednich wersjach kernela – więc tu żadnej pomyłki z mojej strony nie ma. Zaznaczam: chodzi o ten plik ściągnięty bezpośrednio ze stron nvidii, nie o żadne "podróby" gdzieś z repozytoriów jakichś.
Google + nvidia +2.6.25, są patche…. ale lepiej narzekać
Faktycznie, że coś jest – przyznaję, nie szukałem "łat do bloba", według mnie, powinien ukazać się po prostu blob poprawiony – ale, jak na razie, nie znalazłem do 9631 (no, będę jeszcze szukał…), za to znalazłem dopisek: "these patches are provided as-is and may not work on all systems/configurations".
Tak, że nie jestem jednak specjalnie tym ucieszony. Nawet, jeśli się doszukam – przy dowolnej następnej wersji ma prawo znowu nie działać, o czym mnie wyraźnie uprzedzono. Kicha, i tyle.
z: w jaki sposob to robiles? in nvidia way (przy pomocy ich instalatora?), czy in debian way (jak opisywalem – przy uzyciu module-assistant)?
domyslam sie ze piszesz glupoty, bo nie chcialo ci sie poszukac na sieci jak sie to robi pod twoja dystrybucja, tylko na sile probujesz wcisnac to, co udostepnia na swoich stronach nvidia…
hint: sprobuj tego co podalem we wczesniejszym komentarzu…
@Z
A niby co masz w systemie dostarczane inaczej niż 'as-is'?
W trakcie prac, będzie pewno szybciej niż w radeonhd. Możesz sobie aktualną wersję ściagnąć z repo glisse'a.
Aha, jeszcze jedna informacja z komentarzy do wpisu Dave-a. Bardzo mało prawdopodobne jest abyśmy doczekali się serwera X działającego bez roota w każdych warunkach. Istnieje zbyt wiele sterowników do starych kart, których nie ma kto
przepisaćpoprawić.Pod OpenBSD dziala to od dawna, dzieki privilege separation.
Możesz wyjaśnić, jak mechanizm priviledge separation potrafi uruchomić serwer X bez praw roota na openbsd ? Z tego, co się orientuję proces unpriviledged nie ma w openbsd żadnych praw (coś jak securecomp w linuksie) i nie może rozmawiać ze sprzętem.
@thermal: Uruchamianie nie jest tak bardzo istotne jak to, na jakich prawa dziala – po uruchomieniu i zainicjalizowaniu – proces. W OpenBSD (AFAIK, mechanizm znam ze slyszenia, bo OpenBSD nie uzywam) Xorg uruchamia sie na prawach roota (zwykle przez GDM albo inny display manager), uruchamia sobie proces pomocniczy i "zrzuca roota". W tym momencie zagrozeniem moze byc tylko luka w procesie pomocniczym, bo tylko on chodzi na podniesionych prawach. A proces pomocniczy jest, z zalozenia, dosyc prosty i niedziurawy.
"Problem polega na tym, że serwer X na Linuksie działa z uprawnieniami administratora – tak wysokie uprawnienia są mu potrzebne między innymi do zmiany ustawień karty graficznej,"
Nie wiem, może trochę niedoprecyzowano tematu, ale poza tym, że do zmian w konfiguracji rzeczywiście przydają się prawa roota (aczkolwiek i to da się załatwić jak sądzę). Cała reszta chodzi bez żadnego roota.
Kiedyś była taka fajna inicjatywa Kernel Graphics Interface (KGI).
Byla. Splawienie ludzi od KGI pod koniec lat dziewiecdziesiatych bylo jedna z debilniejszych decyzji Linusa.
Trasz, możliwe, że masz rację – możliwe też, że jej nie masz. Można sobie gdybać co by było gdyby Torvalds włączył KGI do Linuksa. Nie wiem jak wyglądał kod KGI gdy był zgłaszany i o co dokładnie był ten cały flamewar.
Dzięki szybkiemu rozwojowi X.org mamy całkiem niezłe eye candy – myślisz, że ludzie zamieniliby teraz compiza na to
http://www.ggi-project.org/resources/images/cube….
?
@optimizationkit: Nie musieliby zamieniac Compiza. Wlaczenie KGI do kernela umozliwiloby przeniesienie driverow tam, gdzie ich miejsce, lata temu. Nie byloby teraz problemow z modesetting itd.
Poza tym, to byl okres, gdy w Linuksie mozna bylo zrobic pewne rzeczy, ktorych teraz, z racji kompatybinosci, zrobic nie mozna. Kto wie, jak by wygladal Berlin (nie, zebym byl fanem tego projektu, ale to inna kwestia), gdyby nie koniecznosc uruchamiania go pod xserwerem?
I jeszcze jedna rzecz – GGI mialo bardzo fajne API. Ja wiem, ze API stateful troche wyszly z mody, ale mam sentyment.
"Wlaczenie KGI do kernela umozliwiloby przeniesienie driverow tam, gdzie ich miejsce, lata temu. Nie byloby teraz problemow z modesetting itd."
Jednak wolę, gdy część sterownika, która potrzebuje większych uprawnień jest w jądrze, a część, która nie wymaga wysokich uprawnień jest w przestrzeni użytkownika.
Według mnie jest to najlepszy kompromis pomiędzy sterownikiem w przestrzeni użytkownika a sterownikiem w jądrze systemu.
Weź pod uwagę to, że sterowniki do kart graficznych są bardzo skomplikowane. Chciałbyś, żeby cały binarny sterownik Nvidii dla Linuksa był w jądrze? Teraz, gdy X się zwiesi podczas używania sterownika od Nvidii w większości wypadków wystarczy go zrestartować. Gdyby był w jądrze systemu, to trzeba by było restartować cały system.
Co do API, to nie wiem, bo nie widziałem KGI
@optimizationkit: Nie o tym mowie. KGI zakladalo przeniesienie do kernela dokladnie tego, co w kernelu byc powinno. Czesc sterownika do karty graficznej owszem, musi byc w userlandzie, ale z powodu wydajnosci – laduje sie w przestrzen adresowa procesu, ktory uzywa akceleracji – nie stabilnosci. Tego KGI nie dotyczylo.
Co do API – powiedzmy, ze "stylistycznie" bylo podobne do OpenGL.
tuż po wycięciu OSS
Tu sie nie zgodze. Decyzja o wywaleniu OSS zapadla w momencie, gdy OSS faktycznie byl mocno do tylu.
Glupia natomiast byla decyzja o stworzeniu dla Alsy nowego, nieprzenosnego, niezgodnego z niczym, nieudokumentowanego, proprietarnego i przekombinowanego API. Duzo problemow nigdy by nie zaistnialo, gdyby ALSA implementowala standardowe API OSS zamiast wlasnego.
Trasz, znowu przekręcasz rzeczywistość. ALSA wspiera API OSS – przyjrzyj się opcją SND_SEQUENCER_OSS, SND_PCM_OSS_PLUGINS, SND_PCM_OSS, SND_MIXER_OSS.
> "proprietarnego"
Można prosić o szczegóły? Chyba że chodzi o GPL (wtedy nie odpisuj – flamy BSD vs. GPL widziałem wielokrotnie),
Opcjom…
@optimizationkit: Wspiera na takiej zasadzie, na jakiej Linux wspiera Win32 – w kulawy sposob, wyraznie oznaczony jako "warstwa kompatybilnosci", ktorego nie powinno sie uzywac w celu innym niz kompatybilnosc w dol.
@uzytkownik: "Prioprietary" w sensie interfejsu zwykle oznacza interfejs kontrolowany przez jedna grupe ludzi, bez zadnego porozumienia czy konsultacji z innymi, inny niz rozwiazania stosowane przez reszte swiata. Zwykle takze nieudokumentowany. Czyli dokladnie sytuacja z Alsa.
"w kulawy sposob, wyraznie oznaczony jako “warstwa kompatybilnosci”"
Bardzo często używam tej warstwy kompatybilności i nie zauważyłem problemów przez które można by było powiedzieć, że ta warstwa jest kulawa.
Poza tym zawsze możesz wrzucić łatki OSS jeśli Ci się nie podoba ALSA.
@Vogel
Racja
@optimizationkit: I jak ci dzialalo nagrywanie albo jednoczesny dostep kilku aplikacji?
Poza tym nie chodzi o "mozesz wrzucic latki". Chodzi o to, ze bez sensownego powodu stworzono nowe, niekompatybilne z reszta swiata API, utrudniajac przenoszenie aplikacji.
"I jak ci dzialalo nagrywanie"
Tego nie sprawdzałem. Jak bawię się gitarą, to używam zwykłego rejestratora dźwięku z Gnome – nie wiem czego on używa.
"albo jednoczesny dostep kilku aplikacji? "
Hmmm… muszę jeszcze sprawdzić (zainstalować mplayera z przyległościami), ale wydaje mi się, że działało bez problemu.
"Hmmm… muszę jeszcze sprawdzić (zainstalować mplayera z przyległościami), ale wydaje mi się, że działało bez problemu."
Nie działa – wydawało mi się, że działa – nie ważne. Nagrywanie sprawdzę jutro, bo rodzina i sąsiedzi nie lubią jak gram w nocy na gitarze :/
optimizationkit: skoro dopiero teraz testujesz/doczytujesz, to po co zabierales glos nie majac wiedzy?
trasz: znowu musze przyznac ci racje :/
sytuacje ratuje ze i ty sie lekko mylisz, bo z twoich wypowiedzi wynika, ze linuksiarze uwzieli sie na reszte swiata i opracowali niekompatybilne api aby reszcie zrobic na zlosc.
alsa, w momecie gdy powstawala – skupiala sie na innych rzeczach. api bylo inne, bo mialo byc profesjonalne, tj. tradycyjne "chcielismy dobrze, ale wyszlo jak zawsze".
to ze zostala wciagnieta do kernela – oss przestawal byc alternatywa – brakowalo sterownikow do sprzetu, a pisanie sterownikow pod alse wydawalo sie (powtarzam: wydawalo) prostrze, bo kod wydawal sie bardziej modularny. dzieki tym mylnym przekonaniom – alsa obslugiwala sporo wieksza ilosc sprzetu, oss mial tez problemy z opoznieniami w nagrywaniu, jak i w hwmixing (ten stary oss, ten z kernela). gosciu ktory pisal oss skupil sie na komercyjnym podejsciu, olewajac to co jest w kernelu linuksowym, tak wiec i oss zostal przez kernelowych maintainerow w duzej mierze olany.
ot i cala historia…
btw. problem alsy to zarowno beznadziejne api, jaki sposob rozwoju (podobny do kernela linuksowego) – przez to jest to tak zabugowany kod.
oss (nowy) jest o wieeele fajniejszy, ale… no wlasnie – pozostaje to ale…
@jellonek
Jak już pisałem "wydawało mi się". Ty jesteś nieomylny i nigdy Ci się nie wydaje?
wydaje mi sie ze jestem omylny
tyle ze staram sie najpierw doczytac w temacie, w ktorym zamierzam sie wypowiadac, a nie po fakcie…