Muke sa Linuxom ovih dana :)

Elem, vikend je... pa rekoh da napisem malo koju o mojim skorijim avanturama sa komandnom linijom :)

Kao sto neki mozda znaju, u mojoj gajbi se znacajno povecao broj Linux masina:

- SIP server: CentOS 5.x
- Linux u Fritz 7570 VoIP/VDSL ruteru (+Busybox)
- Linux u Dreambox DM800 risiveru
- Nexus one sa Linux-om (Android)

Takodje... povecala se i kolicina stvari koje sam morao da kompajliram, broj kernela koje sam bildovao od nule... i tako to :)

Elem, da skratim pricu - imam jednu matoru MSI Mini ITX plocu sa Core 2 Duo procesorom, na kojoj se vrteo taj kucni SIP server, i rekoh da stavim jos neke stvari na nju... trebao mi je jedan mali closed-source server app. koji koristi USB port i ta aplikacija nije open source, vec je closed source...

Uputstvo za tu aplikaciju kaze da radi na Debian-flavored Linuxima, ali ja rekoh, "sta q*** sto ne bi radilo na CentOS-u" i krenuh u hrabri podvig da je nateram da proradi i na mom CentOS SIP serveru..

Elem, hoces malo sutra - aplikacija je ulinkovana sa glibc 2.7, dok CentOS koristi glibc 2.5. Kako dolazim iz Microsoft Windows sveta, rekoh... sta je problem da samo iskopiram glibc 2.7 .so fajlove negde i da to nateram da radi... :)

Hoces malo sutra kako li sam samo naivan bio - glibc je tesko uvezan i sa kernelom i ostatkom Linux sistema, i prosto kopiranje baca segfault, covek moze samo da zaboravi na to :-)) Hmmm... iako je "beyond me" zasto bi hebeni POSIX layer bio tako uvezan sa kernelom da puka promena verzije kernela garant ubija kompatibilnost, otidjoh ja na neke Linux forume da vidim sta se tu moze uraditi...

Rezultat je da ljudi kazu da se NIPOSTO ne bilduje novi glibc i stavlja na zivi sistem, jer moze da sahrani ceo Linux userland te da glibc 2.7 nema sta da trazi na CentOS 5.x i da kome to treba treba da stavi Fedoru 12... wow :) OK ok... ocigledno rec "ABI" nije nesto u recniku nasih vrlih Linux developera... rekoh, dodjavola, moracu da stavim neki Ubuntu ondak.. mozda kao virtuelne masine? DA!! Kao virtuelne masine... odlicna ideja!

Odlucih da Ubuntu 9.10 bude host (posto VMWare ESX-i hypervisor ne podrzava USB sharing sa hosta na guest OS, iako pise da podrzava, podogite kako sam to saznao? ;-)... instalirah ja Ubuntu 9.10 bez problema, i krenuh da instaliram najnoviji VMWare Server 2.0.2...

Hoces malo sutra - za one koji ne znaju, VMWare server ima neke kernel drajvere. Kao sto vec rekoh, kako ABI nije u recniku Linux developera, VMWare installer mora "on the fly" da iskompajlira sve svoje module kako bi radili sa kernelom na masini... OK, to nije nikakav problem jel da - imate perl skriptu, i sve lepo radi automatski?

Malo sutra - VMware 2.0.2 nece da kompajlira svoje drajvere na Ubuntu 9.10 distiribuciji :))) U sred kompajlera izbaci stotine gresaka pa vi mozete da se slikate... tu vec pocinje da mi skace pritisak, odoh na google i nekom srecom nadjem neki patch koji je neki lik napravio, a patch valjda prepravlja nesto u tim drajverima kako bi se kompajlirali sa 2.6.31+ kernelima... OPET pomenuh nekoliko puta ABI i porodicu Linusa Torvaldsa - i instalirah VMware nekako...

Posle toga... namestim ja CentOS kao guest OS sa sve SipX SIP serverom i taj deo, fala bogu, prodje bez problema (tj. bilo je problema, ali su vezani za Javu - a to nije tema ovog posta :-) - red je dosao i na instalaciju tog malog servera na host masini... server se instalirao kako treba, i 'fala bogu glibc je odgovarao... ali sada smartcard reader na USB portu nece da radi:



Kaze Ubuntu kada ubodem doticni reader u USB port... #@)*(&@#(*&(@*&!!!! Sta je sad ovo... opet Google, citaj citaj... kad ono, sta imam da procitam, Kernel 2.6.31 / Ubuntu 9.10 su breakovali FTDI USB drajver... HAHahahaa, opet pomenuh ABI, Linusovu dalju rodbinu ovog puta i krenuh da trazim resenje... ima kao neki patch... nece da radi..

U ocaju sam dohvatio i da editujem .c fajlove i da pokusavam da ih nateram da rade... Ma nista, kako god ga ustekao, uvek ta latency greska... pitam ljude za savet... i znate koji savet dobijem? Stavi Ubuntu 9.04...

EPILOG?

---

Jutros, 04:50h ujutru... zavrsih sa instalacijom prokletinje 9.04 sa VMWare serverom i CentOS-om 5 u guest masini.... i sve konacno radi, posle nekoliko dana maltretiranja sa glibc-om, patchovanjem VMWare drajvera, pokusajima patchovanja USB drajvera...

Znate sta je u stvari najgori deo cele ove price? Najgori deo cele ove price je da je SVE OVO zbog toga sto Linux uopste nema stabilni ABI u svom kernelu, vec svaka nova verzija kernela rusi boga pitaj koliko drajvera.

Ne mogu ni da zamislim koliko se hiljada i hiljada sata trosi prilikom svake revizije kernela, samo na krpljenju stvari da rade sa promenjenim kernelom ... te koliko hiljada sati se izgubi na raznim patchovanjima i maltretiranju sa pokusajima da se nateraju stvari da rade @#)(*@#)(@#

Ne znam sta vi mislite, ali meni je ovo tipican primer izuzetno loseg dizajna :( Znam da on funkcionise, jer ima krdo ljudi i entuzijasta koji svaki dan krpe i krpe taj kod... ali stvarno je pitanje da li je zaista moralo da bude ovako? :(

---

Pa, Linus odavno reče da ga baš briga za ABI kompatibilnost. A izgleda da ga zabole i za rodbinu

A i nas ostale zabole kojima je dovoljno da ostanu unutar monolitnog milog li nam kernela :)

E Dimke, Dimke, pa sta je tu novo ? Ih pa da je u pitanju samo kernel, sta da kazemo za Xorg... Teras xserver 1.7.5 - nema catalysta, nema "detonatora" lol, ako hoces opensource onda nema problema. Ako hoces proprietary, closed source etc. onda patch-uj sine hax0r-u. Dakle ABI se break-uje uvek, to nije nista novo, oduvek je bilo i bice. Iz tog razloga gomila developera radi na opensource drajverima koji ce biti sastavni deo kernela (sa drm bit-ovima) i DDX drajvera koji ce biti sastavni deo xorg-a.

To kopiranje lib-ova nece da mogne, evo pre nekoliko dana bas na es-u postovao lik kako je zeznuo sistem prostim kopiranjem i symlinkovanjem na novu kopiranu biblioteku, segfault-uje sve zivo. Jedva oziveo covek sistem. Ono sto je beyond me je da symlink na originalnu biblioteku ne pomaze posle.

I tako, sto se tice tih closed source zezancija ja zaista ne znam kada ce se opametiti i ponuditi static build ako vec ne daju source, dinamicko linkovanje i closed source je najgora kombinacija koja moze da te zadesi sa nekim software-om. Cak ni opensource neki put ne pomaze jer moras da budzis source, najcesce kokanje sa header-ima i kucanje diff-a i google-anje dok ne snimis gde je koja funkcija pobegla za koju ti kuka gcc. Naprosto software mora da se odrzava inace je dead as disco.

A i VMWare je 3rd party app kao i Vbox, mi zaludjenici ne silazimo sa xen-a i kvm-a... :) Kompatibilno sa kernelom garant - why? Jer je u samom kernelu :P Ko ce bre da taint-uje kernel sa proprietary drajverima i 3rd party modulima :)

---

@Ivan

ESX majka, pa dodaj masine do mile volje... (+VMware vCenter Converter i bog da te vidi )

---

Ma stavio sam prvo ESX - ali je u ESX-u pokvarena USB podrska (iako kazu da "treba" da radi) - dakle, ne mozes deliti USB port virtuelnim masinama !@(*&#@(*&@#



Ma da bre ni meni nije jasno sto nisu staticki ulinkovali..

Mada opet, ako je toliko nestabilan API pitanje je koliko bi i staticko linkovanje pomoglo, jer i ta staticka biblioteka opet moze da zove neke pozive koje su promenili @#(#@

Meni je totalno neverovatno da sve to ipak funkcionise, mislim ima tog Linuxa ne tako malo po svemu i svacemu, a osecam da 2/3 ako ne i vise razvoja tih kernela prolazi u patchovanju i fixovanju onoga sto su pokvarili promenama :)

---

Auh, promače mi taj deo :(

---

Pa evo ja pratim incremental patch-eve za svaku git verziju da vidis cega se sve tu nagledas. Primer (sto je najcrnje ove promene se dogadjaju izmedju point release-ova)

- Enable-uj powersaving feature za intel wireless i IGP-ove
- Disable-uj powersaving za wireless LOL (puca signal ko od sale, a posle S/R-a ne mozes ni da se konektujes)
- Patch-uj powersaving za 945/965 jer zahtevaju specijalni Suspend/Resume handling (C3_IDLE_STATE) - sa ovim sam se licno zafrkavao
- Ulecu quirk-ovi za prepoznavanje statusa LVDS-a na odredjenim modelima jer ne vracaju pravilno status istog
- itd itd itd...

Sad nam je uletela i podrska za overlay od 1500 linija koda, jbt mos' misliti da radi :D

Uglavnom gurkaju se napred/nazad sa feature-ima i ajde da se to dogadja u release candidate ciklusu nego bre izmedju point release-ova imas svakakve gluposti da vidis. Mada iskreno svidja mi se kako napreduju sa nekim stvarcicama (ponajvise integracijom drm koda sa KMS podrskom, sjajan posao obavljaju buduci da im ni AMD ni nVIDIA ne pomazu ni malo, Intelovcima svaka cast opensource all the way).

---

Ivane, imam samo jedno pitanje za tebe. Zašto taj poslić ne obaviš na drugom OS-u? Što bi degojs rekao, OK, shvatili smo, Linux ne valja zbog ABI-ja. Eno ti ih Windows MacOS X, pali brate.

---

Zato sto je neko spreman da svesno prihvati cenu svega toga, ako je zadovoljan onim sto na kraju dobije.
Jednostavno imati mogucnost uvida u ono sto se izvrsava na TVOM racunaru je nezamenljivo.

---

A i bre ko je happy kad sve radi otb, ja bih se smorio posle mesec dana. More sta posle mesec, posle 2 dana. Osim kad imam bitnog posla da odradim :)

---

Pa pazi, iz nekoliko razloga:

a) Serverska aplikacija koju sam pomenuo ne radi ni na cemu drugom osim na Linuxu

b) SIP servera ima za Windows, ali ne besplatnih - a kako ja koristim SIP server iskljucivo iz hobija i zelje da "stick it to the man" mobilnim telefonskim operaterima, zaista nemam ama bas nikakvu racunicu da pljusnem neke masne pare za enterprise SIP server - mislim, u tom slucaju mi se vise isplati da zovem direkt sa mobilnog godinama ;-)

Sa SIP serverom zapravo nisam imao nikakvih vecih problema (osim sa nekim njihovim Java smicalicama) - problem je bio a) - i zapravo, samo pokazuje kolika je kolicina nekompatibilnosti ne samo izmedju raznih distribucija Linuxa, vec cak i izmedju pod-verzija iste distribucije (u ovom slucaju Ubuntu 9.04 i 9.10) i fakat da sve te nekompatibilnosti koje sam ja uocio dolaze zbog jednog problema (nepostojeci stabilni ABI)

--

Da se razumemo, nemam ja nikakvu frku da nesto sam iskompajliram, zbudzim, itd... sto kaze combuster, bilo bi dosadno bez toga. ALI, kada je to budzenje u stvari perpetualno fixovanje necega sto NE BI moralo da bude slucaj, onda se covek zapita zasto je bas moralo da bude tako...

Mada kapiram da "Bazaar" model razvoja Linuxa i neki strogo standardizovani ABI nikako ne bi mogli da se kombinuju, jer bi morao da postoji neko ko bi taj ABI forsirao, a to opet ne bi odgovaralo mnogima, a kako je sve GPL mozda Linux nikad ne bi ni zaziveo vec bi se razvodnio u gomilu forkova.

Ali, svejedno, sa stanovista arhitekture, ovo je jedna jako jako neoptimalna opcija.

---

Pa i Linus rece da je danasnji kernel daleko od onoga sto je on zamislio na pocetku, mislim bas me cudi da je napredovao dalje od par hiljada linija koda :D

Mogu da kazem da je do skoro ovo bio haos, deo toga se reflektuje na Ubuntu 9.04 i 9.10, tek od skoro su se malo dozvali u pamet. Doziveh da vidim stabilni release ciklus x servera, neka pravila oko toga sta ko sme da trpa upstream i u globalu osecam da je poceo da vlada neki "law and order" medju developerima. A i ne mozemo da pricamo o nekom stabilnom ABI-ju na Linux platformi, jednostavno postoji nikakva do gotovo nikakva podrska Linuxu od strane OEM-ova, sve se bojim da ce neki OEM da se potrudi da ispostuje ABI koji postave developeri, njih jednostavno nije briga za Linux i za njihove standarde. Sto, jel MS doteruje quirk-ove raznolikog nam hardware-a, oni jednostavno diktiraju tempo, evo vam drajver model, API/ABI, izvolte pisite drajvere, ako ne radi kako treba nismo mi krivi. Daj taj isti ABI tom istom OEM-u za Linux pa da vidis koliko ce ga biti briga. Realtek i Intel su jedni od retkih koji uopste zele da imaju bilo kakvu podrsku za Linux. Eto videh i da u dsdt tabeli za moj Dell Vostro ima i Linuxa pored Win-a u jednom od branch-eva, izgleda da imam ludu srecu.

Dakle Linux dev-ovi jure i ispravljaju krive drine da bi to sve radilo kako treba, iz tog prostog i jednostavnog razloga nije moguce pruziti stabilan i dugotrajan ABI, menja se prema potrebama vecine da bi sve (uglavnom) radilo kako treba. To je moje misljenje makar...

/edit: I zaboravih da kazem da ni Linuxov monolitan kernel ni iz bliza po arhitekturi ne lici na Win-ov niti je tako zamisljen, naravno tu postoje i zezancije tipa licenci i sl, nije ni svaki oem voljan da pruzi svoje drajvere kao opensource (malo korporativnih tajni itd itd) a trpanje binary blob-ova u kernel je nesto sto verovatno Linusu podize pritisak na 200. Situacija je takva kakva je, samo ne znam kako ce se izboriti sa sve vise i vise koda koji su neminovni u buducnosti, sto vreme bude prolazilo to ce im biti sve teze. Nadam se da ce situaciju ispratiti i povecan broj linux developera pa ce sve ostati manje/vise isto... Jos jedna mana je ta sto se dev-ovi tesko odlucuju na deprecation zastarelih drajvera pa se kernel budzi li budzi...

---

Zasto mislis da OEM-i, ako mislis na proizvodjace uredjaja koji pisu drajvere kao i aplikativne vendore, ne bi postovali ABI?

Ja bas mislim da bi ga postovali, pod uslovom da to neko zaista ponudi.

Problem sa Linuxom je sto je to nemoguce. A evo objasnicu i zasto:

Ako Kernel posmatramo kroz glavne funkcije: dakle memory manager, I/O manager, process manager, itd.. mozemo videti da na raznim delovima tih osnovnih funkcija rade mnoge firme i svaka od njih kontribuira sa nekim inovacijama. Svaka od njih ima apsolutno drugacije zahteve, mnoge od njih rade na razlicitim hardverskim platformama itd.... i svaka od njih komituje svoj kod. Linux onakav kakav je danas je zbir svih tih napora.

Sta u tom danasnjem slucaju mogu da rade Linux maintaineri? Nista. Eventualno mogu malo da ispeglaju taj kod tj. da enforce-uju neke kozmeticke stvari kao sto je coding style, eventualno nesto dorade i to je sve. Kao prvo, u celoj toj ekipi ne postoji nikakav proces koji bi omogucio standardizaciju ABI-ja, a samim tim niko tu nema autoritet da zahteva tako nesto. Jedini autoritet koji postoji je da sve firme moraju da imaju kod koji se kompajlira + coding style - sto je minimum minimuma.

Cak i kada bi imali formalni autoritet tipa sam Linus im je to dodelio - pitanje je koliko bi to uopste funkcionisalo vis-a-vis firmi kao sto su RHEL, Google, Intel itd... na kraju krajeva, sam proces menadzmenta svih requirementa koje te firme imaju bi bio ogroman i skup i zahtevao bi ne tako male resurse + neki "komitet" za standardizaciju. Ne samo to, taj proces bi bio i vrlo spor - moralo bi se sastanciti, pa onda nadglasavati i preglasavati... neki trivijalni feature bi morao da ceka dugo vremena.

Tipa, Google hoce neki novi feature u memory manageru, ali Intelu ne pada na pamet da dozvoli doradu ABI-ja jer recimo nece da menjaju sve svoje module... to bi onda moralo da se ceka, nadglasava - a, zahvaljujuci GPL-u - boga pitaj koliko firmi bi uopste ostalo tu, mozda bi napravili svoje forkove i cao djaci...

Zato i kazem da Linux mozda uopste ne bi ni dosao ovde da nije tako "buvljacki" razvijan...

Da ne pricamo o tome da bi stabilni future-proof ABI zahtevao odlicno planiranje od samog starta, a to se nije desilo. Bilo bi teoretski nemoguce to poceti u ovom momentu - mozda jedino kao 3.0 kernel, ali i to je diskutabilno jer bi se i od 3.0 kernela ocekivalo mnogo u samom startu.

--

Microsoft je tu u sasvim drugoj situaciji - jer su oni od samog starta bili jedini koji odlucuju o ABI-ju a i glavna komercijalna prednost PC platforme jeste bio backward-compatibility, sto je njihove manager-e i te kako motivisalo da uloze $$$ u razvoj stabilnog ABI-ja, sto su postigli kupovinom ljudi kao sto je David Cutler & co..

---

Ne bi jer im nije u interesu, mali broj korisnika - ne pada im na pamet. Ok ove igrace dole sto si naveo njima jeste u interesu, sta boli dj Logitech-a ili recimo Creative da razvija drajvere za platformu na kome i nema mnogo korisnika a ni app-ova da bi se njihovi proizvodi exploatisali. Ne zele jednostavno da ulazu kintu u razvoj drajvera i podrske na Linuxu - a i zasto bi kad ima ludih g33k-ova koji ce taj posao obaviti umesto njih. A ono sto Intelu i Google-u odgovara da urade na Linuxu oni to vec i rade i imaju ekipu zaduzenu za to. Intel je cak i ditch-ovao Tungsten i okrenuo list i sam odradio from scratch njihov memory manager i akcelerator, dok je Anholt i ekipa koji rade na ati-jevim drajverima nastavila sa TTM-om.

---

Pa da, ali opet- to "budzenje" im je dozvolio Linux dizajn. Linux uopste i nema stabilni ABI, pa da mozes nekog da krivis da ga se ne pridrzava - jednostavno, sve moze da se promeni u bilo kom trenutku (i menja se!) i ocekuje se od drajver developera da konstantno patchuju svoj kod kako bi radio sa novim revizijama kernela.

Mada, opet, ako je sistem otvorenog koda - uvek se moze "budziti"... ali u slucaju "haoticnog" ABI-ja neke firme imaju jos veci razlog za budzenje jer su pod utiskom da sa svojim proprietary BLOB-ovima i sl.. umanjuju kolicinu interakcije koda sa Linux ABI-jem koji se menja.

Taj BLOB pristup je jos gori, jer ukoliko firma digne ruke ili nema interes, mozes da se pozdravis sa drajverom. Medjutim, sve i da je kod otvoren i cak i da postuju sve trenutne "propise", opet neka nova verzija kernela zahteva da neko sedne i patchuje taj kod. Kao sto vidimo, Google je bio isteran iz staging branch-a jer nije odrzavao svoj kod... ako Google to ne radi, ne mozes bas ocekivati od manjih vendora da to konstantno rade.

Kokoska i jaje problem :(

Nemam cifre pa da pokazem ili dokazem koliko je patch-vanje postojecih drajvera problem, ali definitivno CEGA GOD sam se ja dohvatio, uvek je bio neki problem izmedju verzija - sto meni dosta govori o tome da se ne tako mali broj sistemskih poziva ili ponasanja istih menja.

---

Si probao Citrix?

doduse nisam koristio USB-ove ... COM port deljenje jesam i to je radilo solidno...

---

Aaaa, znači Linux je ipak, sa svim svojim manama, u ovom slučaju bolje rešenje od Windows-a.

---

Pa ako nemas nekog specificnog hardware-a za koji moras da kalemis proprietary drajvere - to budzenje i brljanje sa API-jem se i ne oseti - sto je normalno :) Cim pokusas da pokupis "najnoviju" verziju drajvera iz 2007-me (do tad je razvijali i posle batalili) - ja uopste ne sumnjam da ce iskociti neki error tokom kompajliranja. Eto cist primer je intelov 536ep modem drajver koji je bio razvijan dugo vremena i koji je jedini radio kako valja u to vreme pa su sami Intelovci popizdeli zbog tako cestih promena ABI-ja da su batalili odrzavanje istog. Onda je Philippe Vouters nastavio sa njegovim budzenjem jer ga nije mrzelo ali evo problema recimo:



Dakle delom firmware, BLOB, i sta da radis...

Pa onda nouveau dev-ovi, zamalo najebase (da izvinete :)) zbog ctx_voodoo firmware-a a nVIDIA samo sedi sa strane i smeska se i gleda sta ce geekovi sad da urade. A geek-ovi ne bi bili g33k-ovi da se nisu iznervirali i napisali firmware from scratch i :P

Pa onda cela zajebancija oko poulsbo-a i njihovog firmware-a, to si na svojoj kozi osetio koliko moze BLOB da te zajebe i kad moras da cekas devove da se smiluju i da taj firmware bace u bin i napisu nesto normalno kao zamenu.

---

Aaaa, znaci otkrio si Ameriku. Naravno da je bolje resenje, zato ga i u tom slucaju koristim... ne secam se da sam ikada u zivotu rekao da Linux ne valja nicemu, svasta.



Hmm hmm... drajver koji je 2.6.31 kernel skrsio u mom slucaju je FTDI usb smartcard drajver, koji nije proprietary. Koliko ja ovde mogu da vidim, izgleda nisu primetili da su ga skrsili, tj. nije bilo dovoljno testova. To je jos jedan od problema.

Onda je ekipa iz SAT community-ja pocela da kuka (jerbo se taj drajver jako cesto koristi za pristup USB citacu satelitskih kartica) - pa ce sad morati da fixuju.

Do tada, za svaki novi 2.6.31.x moras da primenis neki patch - mada, kao sto rekoh, u mom slucaju ni taj patch nije pomogao.



Poulsbo je definitivno najnesrecniji slucaj - medjutim on u celu pricu dodaje jos jednu dimenziju, a to je nepostojeci VA (video acceleration) standard u Linuxu....

Mada, glavni i najveci problem Poulsbo drajvera nije taj BLOB (koji komplikuje stvari, da se razumemo), vec "previse babica" na projektu (ImgTech, Tungsten, Intel) - najpametnije je bilo da je Intel u samom startu odlucio da raspise taj drajver od nule - ali...

Takodje, Intel ima vise tipova svojih drajvera - imate te skroz OSS drajvere, onda IEGD komercijalne koji su closed-source (uzgred, u slucaju Poulsba smo proveli vise meseci prijavljujuci bugove i radeci sa Intelom na fixovanju istih), i - u slucaju Poulsba, jos jednu liniju tzv. "UMG" ili GMA500 liniju drajvera.

Pouslbo nije imao dobru OSS podrsku (nema je i dalje) - vec je postojao samo neki kvazi OSS drop sa tim BLOB-om, koji je u stvari GMA500 branch....

Uzgred, kada smo vec kod Poulsba - Intel radi na novoj verziji (skroz novoj) drajvera za Tunnel Creek potpuno drugacijih i "od nule"... ali ne znam koliko ce smeti da open-sourcuju nisu 100% bazirani na Intelovom kodu (opet)

---

Da bre, oni vuku taj PowerVR design, ma bas me briga, nemam ja toliko toga ni protiv firmware-a (osim ako gov*o nije pisano BC i ako ne vuce neki bad ass legal stuff sa sobom) ali je naravno preporucljivo da bude otvoren, cisto zelim da znam da je alternativa moguca ako se OEM smori od unapredjivanja drajvera posle... Ma Linus sa pravom je obazriv sto se trpanja firmware-a tice u kernel.



Da, lose sam se izrazio, moze drajver da bude i otvoren pa da pravi probleme, mislim svasta, po neki put ni drajver u kernelu ne radi kako treba pa cekas patch, samo su vece sanse da ce se funkcionalnost njegova pre povratiti nego 3rd party opensource drajvera (da ne pricamo o proprietary drajverima). Makar sa opensource drajverom mozes da se bakces, da ti makar neku nadu da nesto mozes da uradis, naravno sanse su ti male ali postoje :)

Evo sad distro devovi zivi nisu i ne znaju sta da rade sa nouveau drajverom, doslo opet do ABI break-a u 2.6.33 (kada posmatramo external branch i mainline posto je nouveau tek sad uleteo u staging), pa ljudi ne znaju sta da rade, kazu da se stvari odvijaju isuvise brzo da bi ih pohvatali (izgleda da g33k-ovi rade punom parom).

A intelovci su zakon, 6 meseci je postojala podrska za Ironlake pre nego sto je ugledao svetlost dana, evo sad i za Sandy Bridge su krenuli opet na vreme, ma gotivim ih nenormalno... :)

---