Egy újabb patch Greg-től

Linux

Greg Kroah-Hartman blogján jelent meg egy bejegyzés, amelyben közzétett egy általa készített és "viccesnek" titulált patch-et, amivel szeretné a zárt forrású (binary-only) eszközmeghajtó programokat író, és azokat az eszközöket használó cégeket/egyéneket kicsit elgondolkodtatni.
A patch annyit tesz, hogy letiltja a PCI alrendszerhez tartozó funkciók elérését nem GPL licencelésű driverek/programok számára.

A bejegyzésben kiemeli, hogy tisztában van vele, hogy a jelenleg érvényben lévő kernel szimbolokat érintő szabályozások miatt egy ilyen patch-et nem lehetne elfogadtatni, de elméleti szinten azért boncolgatja a témát. Kissé fenyegtő hangnemben az olvasónak szögezi a kérdést, hogy mit tenne abban az esetben, ha egy ilyen kód elfogadásra kerülne a mainline kernelbe, hogy magyarázná meg a főnöknek/ügyfeleknek, hogy miért nem működik az adott eszköz Linux alatt.

"Ha Te vagy céged zárt forrású kernel modulokat használsz, napjaid meg vannak számlálva." - írja Greg.

A bejegyzés itt, a patch pedig itt található.

> Szerinted az igy kapott geped ugyanolyan stabil lesz?

Na igen, az ilyen "elvarazsolt" hardverekhez az opensource driver is iszonyat stabil? En majd "szabadon???" eldontom hogy akarok-e instabilat, de legalabb mukodot, vagy semmilyet. Azt hittem ez az elvarhato mukodes. Ha nagyon vicces akar lenni akkor rakjon bele kernel opciot, es mindenki eldontheti kernelforditasnal, hasznalja-e a binaris driver interfacekat vagy sem

Es akkor most a teljesitmenyproblemaktol eltekintettunk, amit a userspaceban futtatas okozhat.



Egyik kernelfejleszto is irta, hogy 5-10%-al is lassabb lehet (vidkartyara irta), de valamit valamiert (stabilitas vs. sebesseg).

Pontos linket nem tudok (fejbol irtam), es most nem talalom hirtelen.

Az egyseges API-val az a gond, hogy szerintuk a fejlodes utjaban all. (Es a kesobbiekben egy-egy nagyobb API valtas sokkal nehezebb (pl. mar nem fejlesztenek drivert tobb eves cuccokra).

Jo pelda erre a windows. Meg a mostani XP64bites kiadasa. Alig van driver ami muxik rajta, es a kartyak joreszehez mar nem is adnak ki drivert. (pl: mar nem gyartja a drivert a gyarto)

khiraly írta 2005-11-22 13:01 -n:
> _"Szoval ha valaki binaris driverekkel akar ganyolni, megteheti, de ne a
> kernelbe rakja bele a szarjat."
>
> tehat: a binaris drivert irok mind balfaszok, akik ***** kodot irnak,
> ellenben az opensourceistenek kivalo koderek?_
>
> Nem ugyanugy fejlesztik, mint a kernelt. Igy a minosege se lesz ugyanolyan
> (lehet jobb v. rosszabb). Raadasul a kernelfejlesztoknek kellene a binaris
> driver irokhoz alkalmazkodni ...

Vagy eppen a kernel hackereknek irni egy normalis, stabil, egyseges
driver interface -t, ami nem valtozik minden egyes alverzio-valtasnal

> Egyebkent a binaris driverek a bsd-knek valok, lehet azt hasznalni;) (ez
> mar poen akart lenni)

Ha van eszuk a driver iroknak, akkor inkabb oda osszpontositanak...
(ez meg nem poen akar lenni, annak ellenere, hogy enis egy linux
disztrot hasznalok)

engem nem erdekel, hogy mik _vannak_, hanem az, hogy miket _hasznalok_. erzed a kulonbseget?

Jaja erzem. Minden hardvervasarlas elott tobb hetig tanulmanyozom a netet a linuxos tamogatasa miatt. Es meg igy is neha porul jarok. Nem tudtam olyan notebookot valasztani amiben mindenhez lett volna driver, szoval most azt hasznalok belole amit tudok. Erzem a kulonbseget.

Amit hasznalok ahhoz van driver ...

khiraly írta 2005-11-22 12:56 -n:
> broadcom-os wifi vezerlo. Ez lemaradt.
>
> De irhatok meg media kartya olvasot(5-in-1 texas instrument), winmodemet is
> (szerencsere ez mar kihalofelben)
>
> Hmm, alig maradt olyan cucc a gepbe, amihez opensource driver kellene;)
> (bill, eger)
>
> Szerinted az igy kapott geped ugyanolyan stabil lesz?

Szerinted az Xorg -os opensource nv driver es az opensource ati driver
olyan kifogastalan minosegu. Mind2 ugy bugzik, mint allat...

Ebredj fel teis.

Hmm nezzuk csak. Binaris nvidia driverevel nem mukodik (jobban mondva egyik laptopon igen, a masikon nem. Ugyanaz a marka es tipus, csak egyikben 32MBos a masikban 64MBos valtozat van) a hibernacio (suspend2 modul).

Most varhatok, hogy majd a gyarto meltoztatik fixalni a cuccot. Holott valszeg egy C kodot latott ember (eleg idovel) is meg tudna fixalni. Talan meg en is... (reportolni biztosan tudnek)

De olvasni olyat, hogy valakinek X verzioju driverevel mukodik es az ujabb nvidia driverrel mar nem (vagy forditva)...

LGB wrote:
> Nem erted, latom. A Linux kernel egy monolitikus kernel, eltekintve attol
> hogy "kulonleges" szerepkorben van a kernel EGYETLEN program! Semmi koze
> egy masik "kulso" teljesen mas elven felepulo dolognak hozza, ez ugyanolyan
> mintha egy XYZ GNU/GPL programba valaki egy binaris cuccot akarna
> beleeroszakolni "kivulrol". A kernelnek nem celja hogy belso komponensek
A sendmail is egyetlen program, mégis lehet hozzá miltereket kapcsolni.
És ott sem változik naponta az API.

Driverirassal nincs tapasztalatom. De mar irtam olyan webmail feluletet, amit mas kezdett el es en egy olyan 8honap alatt fejeztem be. Ha lett volna esszeru alternativa lehet sose fogok bele. A kenyszer vitt ra.

Most is irok egy masik programot, amibol nincs normalis alternativa (zart forrasu se). Itt is a kenyszer visz ra.

Talan igazat mondok azzal, hogy a driver irasi kedv igy csokken:

* nincs opensource driver, nincs closed se

* nincs opensource, de van closed

* van opensource driver

( MrCrowley | 2005. 11. 22., k – 14:36 )

"Ha Te vagy céged zárt forrású kernel modulokat használsz, napjaid meg vannak számlálva."

Nagy nyilvánosság előtti életveszélyes megfenyegetés? :))

( Csigaa | 2005. 11. 22., k – 14:37 )

Hehehe jót nevettem :P Ez egy fatális barom...

A Linux ha így folytatja kinyírja magát. Lassan ugyanaz lesz, mint a politika... Szarban vannak, de konkrét megoldások helyett csak mocskolódni tudnak...

Vegeredmeny: Nincs opensource driver hozza.

A fentebb emlitett hozzaszolasokbol elolvashatod, hogy pl miert lehetseges, hogy a gyarto nem ad ki semmit. Ellehetetlenitik a binaris driverek fejleszteset, igy semmilyen drivered nem lesz, hat ez valoban franko lesz.

Az meg kulon jo vicc, hogy opensource driver melle toltod a binaris firmwaret, mert azt mar rohadt sok idobe telne ujrairni. (jo, persze az nem teszi "instabilla" a kernelt)

nagyon ne mertelek zsirfeka. ha nem tetszik a nyilt forras, hasznalj windows, AIX-et, HP-UX-ot,...

ha meg tetszik a nyilt forras, de nem tetszenek a linuxos driverek, hasznalj BSD-t.

A linuxban ideiglenes megturt dolog a binaris driver. mar kozep tavon sem lesz tendencia, hogy bennmaradhat. olvasd el Linus levlistas leveleit.

ez nem egeszen ilyen egyszeru, megha ti le is egyszerusititek.

szerinted ez ugy mukodik, hogy "a nyilt forras jo", "a zart forras rossz", "a linux/bsd/whatever jo", a "windows rossz"? "linus jo", "gates rossz", "andrew morton jo", "steve ballmer rossz"?

a nyilt forras egyfajta megkozelites, fejlesztesi modell, szemleletmod. NEM eletmod, NEM az egyetlen ut, hanem egy a lehetsegesek kozul. van amikor jo (sok esetben), es van, amikor nem. igy aztan ahol kell, ott zart forrasu rendszereket hasznalok/hasznaltam, ahol lehet es megfelelo, ott nyilt forrasut.

ettol meg nem tetszhet az, ahogy szejjelvagjak a linuxot, ami bar sosem a "tisztasagarol" (ertsd: erdekes es sokszor csunya, de ugyanakkor sokszor valoban celravezeto hekkek) volt hires, de jo, megbizhato es stabil rendszer volt es pontosan azert szerettem (szerettuk) mert sok esetben/helyzetben udito, jol hasznalhato alternativat jelentett az akkor meg zomeben mas hozzaallasu tobbseggel szemben.

en pont azert vagyok duhos, mert azt latom, hogy ez valtozik: ugyanaz az arrogancia es "majd mi megmondjuk, mi neked a jo" hozzaallas lesz a linux core fejlesztok sajatja is, amiert annak idejen karhoztattuk a cegeket.

A Linux kernel licensze a GPL. A GPL licensz sajatossaga, hogy a GPL licenszu kod nem keverheto, es nem linkelheto nem szabad licenszu koddal.

A Linux modularis szerkezete miatt egy zart forrasu drivernel kodkeveres nincs, viszont nem tiszta (szurke :), hogy egy zart forrasu modul behozasat, azt tiltja-e a GPL, vagy nem. egyelore nincs kidobva, de elobb utobb ki lesz. ez nem ma kitalalt dolog.

A BSD licenszben nincs ilyen kitetel. barmelyik gyarto csinalhat zart forraskodu drivert akarmelyik BSD-hez.

Ha olyan elemi igeny van a zart forrasu driverekre, akkor at kell terni BSD-re, es ahhoz a gyartok kedvukre keszithetnek zart forasu drivereket nincs jogi akadalya. Bar kivancsi lennek, hogy TdR mit szolna hozza, ha valaki benn akarna latni a OpenBSD-ben a zart forrasu driveret.

De mivel a Linux opensource, akar te is leforkolhatod, es kiadhatsz egy olyan kernelt, amiben ott van egy szep binaris driver gyartok altal szeretett API. Ha tenyleg akkora az igeny erre, akkor majd minden oprendszer gyarto szepen atter a te kerneledre. nevezheted mondjuk zsirux-nak:) A linux nem az egyetlen ut, hanem _egy_ ut. Ha te arra mesz akkor neked is jo, ha nem arra mesz valasz/epits masik utat.

> ha valaki benn akarna latni a OpenBSD-ben a zart forrasu driveret.

Nem akarja benne latni senki, ahogy a linuxban sem. Azt szeretnek latni az emberek, hogy lehetoseg legyen hasznalni ezeket a modulokat. Hogy ez mennyire szurke a gpl-nel, azzal nem szallok vitaba, de ez a lepes szerintem nem ezen mulik. Ez csak erofitogtatas: Akkora majerek vagyunk mar, hogy ezt is megtehetjuk. Aztan majd lesz kmembe patchelo, binaris-driverloader vicc, az jobb lesz barkinek is?

Figyeljetek már! A dolog mára már egy kicsit továbbment a 20 éves srácok hackelnek otthon kategóriánál, debian az isten, meg egyéb vicces dolgokon. A linux ma már üzlet. Az üzlet meg a pénzről szól, és az ügyfelek meggyőzéséről. Hogy nekik jó, ha linux-ot használnak (mert az Oracle xy gyorsabb, mint windozia alatt, kevesebb a vírus, jobb menedzselhetőség, és egyéb marketing szövegek) A felhasználó számára, bármilyen meglepő, elsődleges szempont, hogy az eszközeit használhassa. Azóta, amióta a Linux üzlet lett, bizony rengeteg fejlesztő céges pénzen fejleszt bele (kezdve kde/gnome, egészen a kernelig). Ezt el kell fogadni.

Egy átlag felhasználót baromira nem érdekel, hogy bináris driver van, vagy opensource, vagy egyéb varázslat. Ő csak használni akarja az eszközeit. Egyelőre még desktop-on nem akkora piac a gnu/linux (bármennyire is szeretnénk), hogy egy ilyen megoldás (bináris driverek tiltása) "megtorlás" nélkül maradna, és ezt egyetlen nagy cég, amely a linuxos fejlesztést támogatja, sem nyelné le könnyen, szvsz nagyon komoly visszalépés lenne.

Persze, a legjobb az opensource driver, amibe bele lehet hackelni, ha valami sz@r, de én pl. örülnék, ha a scanneremhez akár csak bináris driver lenne (xerox one touch 4800)

Idővel persze ki lehet kényszeríteni a cégeket, hogy nyissák meg a forrásaikat, amennyiben ez lehetséges, de most még nem érzem elérkezettnek az időt erre.

"viszont nem tiszta (szurke :), hogy egy zart forrasu modul behozasat, azt tiltja-e a GPL, vagy nem. egyelore nincs kidobva, de elobb utobb ki lesz. ez nem ma kitalalt dolog."

mas dolog az explicit tiltas es mas dolog a megtures. tudtommal ez nem GPL-related problema, persze lehet, hogy tevedek.

linus errol ezt irja:

"But one gray area in particular is something like a driver that was originally written for another operating system (ie clearly not a derived work of Linux in origin). At exactly what point does it become a derived work of the kernel (and thus fall under the GPL)? THAT is a gray area, and _that_ is the area where I personally believe that some modules may be considered to not be derived works simply because they weren't designed for Linux and don't depend on any special Linux behaviour."

ez azert nem teljesen ugyanaz, mint amirol te beszelsz.

"De mivel a Linux opensource, akar te is leforkolhatod, es kiadhatsz egy olyan kernelt, amiben ott van egy szep binaris driver gyartok altal szeretett API. Ha tenyleg akkora az igeny erre, akkor majd minden oprendszer gyarto szepen atter a te kerneledre. nevezheted mondjuk zsirux-nak:) A linux nem az egyetlen ut, hanem _egy_ ut. Ha te arra mesz akkor neked is jo, ha nem arra mesz valasz/epits masik utat."

ez egy igen remek kis gondolat, engedd meg, hogy elsokent gratulaljak hozza.

In article <42.58101@c.hup.hu>, khiraly wrote:
> chippekhez probalnak opensource drivert irni. Mondhatnad, hogy irjanak, meg
> akinek ideje van varja ki. De ha megnezed, hogy kik is fejlesztik, szinte
> az *osszes* fejleszto PPC platformrol jon (apple gepek foleg).

Ehhez annyit tennek hozza, hogy aki Apple gepre nem MacOS-t tesz, az meg
is erdemel mindent.

--
Gabucino

linus errol ezt irja:

"But one gray area in particular is something like a driver that was originally written for another operating system (ie clearly not a derived work of Linux in origin). At exactly what point does it become a derived work of the kernel (and thus fall under the GPL)? THAT is a gray area, and _that_ is the area where I personally believe that some modules may be considered to not be derived works simply because they weren't designed for Linux and don't depend on any special Linux behaviour."

ez azert nem teljesen ugyanaz, mint amirol te beszelsz.

erre gondoltam, de rosszul emlekeztem,bocs

In article <42.58144@c.hup.hu>, Mészáros András wrote:
> A Linux modularis szerkezete miatt egy zart forrasu drivernel kodkeveres
> nincs, viszont nem tiszta (szurke :), hogy egy zart forrasu modul
> behozasat, azt tiltja-e a GPL, vagy nem. egyelore nincs kidobva, de elobb
> utobb ki lesz. ez nem ma kitalalt dolog.

Magyarul nem tilos, ergo szabad. Az egyetlen problema az, hogy az onjelolt
kiskiralyok fanatizmusa diktalhat ilyen helyzetben.

Szerencsere ezt elore lattam es idejeben valtottam. Most nincs mas dolgom
mint hatradolni es rohogni ahogy osszeomlik az egesz :) Ki tudja, talan 3 ev
mulva megint normalis lesz a linux.

--
Gabucino

In article <42.58088@c.hup.hu>, Mészáros András wrote:
> barmelyik opensource oprendszer hamar tonkremenne, ha elterjednenek a zart
> forrasu driverek.

Igy elso korben kopni-nyelni nem tudok ekkora baromsag olvastan.

> Az M$-nak sok penzt megerne, hogy lefizessen driver programozokat, hogy
> instabilla tegyek a rendszert.

Hmmmmm. Tehat az MS irna binaris drivereket? Mihez? Az egereihez?
Komolyan, ennyi MS-utalo arcot mint itt, nem egyszeru :)

> a driverek a monolitikus kernel reszei.

Ez minden bizonnyal egy ertelmes, jelentosegteljes mondat.

> GKH modszere nem a legjobb, de valami kellene, hogy visszaszoruljon a zart
> forraskodu driverre valo atalas tendenciaja.

Read my lips: a linux elerkezett a hataraihoz.

Ennel openszorszabb egyhamar nem lesz. Most a linukkksz a kovetkezo
valasztas elott all: kompromisszum, vagy jelentos visszaeses. Illetve GKH-ek
mar tudtukon kivul meghoztak ezt a dontest.

--
Gabucino

Gabucino írta 2005-11-22 16:00 -n:
> In article <42.58088@c.hup.hu>, Mészáros András wrote:
>>forraskodu driverre valo atalas tendenciaja.
>
>
> Read my lips: a linux elerkezett a hataraihoz.
>
> Ennel openszorszabb egyhamar nem lesz. Most a linukkksz a kovetkezo
> valasztas elott all: kompromisszum, vagy jelentos visszaeses. Illetve
> GKH-ek
> mar tudtukon kivul meghoztak ezt a dontest.

Furcsa, hogy ilyet mondok, de ebben ugy latom, egyet kell ertenem Gabuval...

tehat akkor a hupdroid allaspont szerint ossze kene fognunk, es vagy csinalni egy sajat linux-forkot, esetleg nullarol irni egy uj operacios rendszert. persze mehetunk az LKML-re is sirni, kar, hogy a homokozoban kemenykedo fomajereket a sajat (termeszetesen hibatlan) nezopontjukon kivul eso dolgok nem erdeklik.

na mindegy.

( snq- | 2005. 11. 22., k – 17:19 )

1. Mr Kroah-Hartman belepeccseli

2. Te/en/a disztrok kpkg maintainerei/epeszuek kipeccselik

3. ???

4. Profit!

problema?

In article <42.58159@c.hup.hu>, zsirfeka wrote:
> tehat akkor a hupdroid allaspont szerint ossze kene fognunk, es vagy
> csinalni egy sajat linux-forkot, esetleg nullarol irni egy uj operacios
> rendszert. persze mehetunk az LKML-re is sirni, kar, hogy a homokozoban
> kemenykedo fomajereket a sajat (termeszetesen hibatlan) nezopontjukon kivul
> eso dolgok nem erdeklik.
>
> na mindegy.

Eskuszom, a linuxot azert talaltam ki hogy en szetrohogjem magam :D

--
Gabucino

( bra | 2005. 11. 22., k – 18:41 )

frank wrote:
> A patch annyit tesz, hogy letiltja a PCI alrendszerhez tartozó funkciók
> elérését nem GPL licencelésű driverek/programok számára.
Épp ma vitatkoztunk a kollegával erről. :)

Nekem személy szerint ellenszenves az a hozzáállásuk, hogy csak a saját
szekerüket tolják (gyk: GPL->Linux), nem pedig a nyílt forráskódét.

Sajnálom őket.

khiraly wrote:
> Raadasul ehhez hozzajon meg, hogy szerintuk illegalis binaris drivert
> loadolni a kernelbe. Oldjak meg ugy, ahogy az ndiswrapper, vagy csinaljanak
> opensource drivert.
Miért illegális linuxos bináris drivert betölteni és miért nem az
windowsos esetében?

Ha írok egy linbinwrappert, akkor az jó?

zsirfeka wrote:
> tehat: a binaris drivert irok mind balfaszok, akik ***** kodot irnak,
> ellenben az opensourceistenek kivalo koderek?
Egyáltalán hogy lehet bináris drivert írni? :)))

> " hanem az SCSI es SATA binaris driverek teruleten. Ahol a stabilitas
> nagyon is fontos tenyezo, amit binaris drivereknel nem lehet garantalni."
> miert? ki nem tudja garantalni? greg kroah-hartman? andrew morton? irjon a
> gyarto tisztesseges kodot.
Komolyan elgondolkozom azon, hogy ezek után hogy működhet a Windows, az
OS X, vagy bármi más, amihez a gyártók a felhasználóknak bináris
formában adják a drivereket.

khiraly wrote:
> Pl. nem valtoztatjak meg az API specifikacioit x evig.
Előre kéne tervezni, mi?

Teljesen korrekt. A 2.4-es Linuxhoz van egy rakás driver, ami a
2.6-osban már nem működik, pedig nyílt forrású, de a megváltozott
környezetbe már senki sem portolta őket.

Hogy is van ez?

_Joel wrote:
> Micsoda szabadság...
Ezt már megbeszéltük, de leírom mégegyszer (nem neked): ha ezek a
linux-arcok tényleg a szabadságot tartanák szem előtt, akkor nem GPL-es
driverekért sírnának, hanem szabadon hozzáférhető, részletes
dokumentációért. Ahogy OpenBSD-éknél is szokás.

Persze *ezen felül* írhat a gyártó drivert is, felőlem akár GPL-eset is.

( whitehawk v | 2005. 11. 22., k – 19:08 )

Ha van egy nyílt forráskódú rendszer, ami létrejött, hogy mindekihez eljusson, akkor igenis ki kell állni a nyíltsága mellett, és tenni azért, hogy ne kerüljenek bele zárt forrású kernel modulok. Lehet, hogy nem a G. K-H. féle megoldás a jó, de mindenképpen ösztönözni kell a hardver gyártókat, hogy specifikációt adjanak a chipjeik mellé, amihez lehet szabad drivert írni. És amikor licenszelnek technológiát, vagy építenek egy eszközt akkor azt úgy tegyék, hogy ahhoz nyílt forrású driverek lehessenek.

A Linux kernel megszületésekor ugye rövid ideig még a GPL feltételeinél is szigorúbb licensz alatt került közkézre, ami mindennemű kereskedelmi lehetőséget tiltott. Ha azt vesszük, hogy a GPL egy cserekereskedelmi licensz. Azzal fizetsz, hogy amit hozzáraksz, azt közre adod. Jogos elvárás, hogy ezzel ne éljen vissza senki, és igenis adjon vissza a közbe.

zsirfeka wrote:
> "But one gray area in particular is something like a driver that was
> originally written for another operating system (ie clearly not a derived
> work of Linux in origin). At exactly what point does it become a derived
> work of the kernel (and thus fall under the GPL)? THAT is a gray area, and
> _that_ is the area where I personally believe that some modules may be
> considered to not be derived works simply because they weren't designed for
> Linux and don't depend on any special Linux behaviour."
Néha elgondolkozom, hogy hol tartana a nyílt forráskód GPL nélkül.
Gondoljatok bele ti is: nem termelődne ennyi bitszemét és a felszabaduló
időben kódolhatnának az illetők, vagy megnyugodhatnának és új gondolatok
vetnék meg magukat a fejükben.

Sokkal jobb lenne a világ. :)

Gabucino wrote:
> Sehogy bazeg, linux az isten :)
Na igen. Lehet, hogy a legtöbbet tudó Unix-szerű OS, meg szinte mindent
meg lehet vele oldani, de nekem jópár éve elment már tőle a kedvem...

Meg a GPL-től is. Hülye vagyok én ehhez, de láthatólag nálam sokkal
nagyobb elmék is azok, hiszen nyíltan leírják, hogy nem tudják, hogy a
GPL ezt, vagy azt megenged-e.

Akkor ne legyen semmilyen licensz alatt. Legyen public domain,
gyarapítsa az általános emberi tudást, vagy ne csinálják a színjátékot
itt ezzel a "szabadságért harcolunk" szöveggel, amikor valójában csak a
saját szekerüket tolják.

Nem errol van itt szo szerintem ... Csak ha pl nvidia, akkor mar azonnal nem biztos hogy mindig valthatok barmilyen kernelre ha akarok 3D gyorsitast is, mert ugye az egy closed source cucc, nem nagyon van mod senkinek belenyulni, marmint persze az emlitett nvidia driver eseten a "glue" kodba igen, de a lenyegi reszbe sajna nem es ha esetleg ott kene? Ami a kernelban van cucc, az viszont GNU/GPL barmikor megnezheted, atirhatod, stb, barmilyen elvetemult patch halmaz feltetele utan is van valoszinusege h mukodik marmint ha valaki NAGYON ert hozza hogy megfeleloen csinalja :) A lenyeg hogy closed source eseten ennek a lehetosege sem adatik meg es hozza vagy lancolva azokhoz a dolgokhoz amit a driver iroja tamogat: ha mast szeretnel hasznalni de pl nvidia azzal nem megy akkor ennyi volt ... Arrol nem is beszelve hogy a megy/ nem megy dolognal van "arnyaltabb" is, pl a "neha fagy" kategoria ;-( Az meg ugye meg rosszabb ...

whitehawk wrote:
> hogy ne kerüljenek bele zárt forrású kernel modulok. Lehet, hogy nem a G.
> K-H. féle megoldás a jó, de mindenképpen ösztönözni kell a hardver
> gyártókat, hogy specifikációt adjanak a chipjeik mellé, amihez lehet szabad
> drivert írni. És amikor licenszelnek technológiát, vagy építenek egy
Ez a "specifikációt adjanak a chipjeik mellé" szöveget rajtad kívül más
is említette ebben a témában? (nem néztem meg GKH oldalát, de itt eddig
nem erről volt szó).

Hat tudom Gabu hogy ebben nem egyezik meg a velemenyunk, de szerintem rugjak is fel nyugodtan ha ez BARMI elonyt jelent! Azert kell pont open source kernel fejleszteseket csinalni, mert akkor ez nem tul nagy problema. Vannak bizonyos zart forrasu rendszerek akik nagyon buszkek ra hogy ok kompatibilisek mindig sajat magukkal aztan az egyik programverzio mar nem olvassa a megelozo forumatumat, vagy a kovetkezo OS-en nem fut a megvasarolt programod, meg hasonlok, egy meg nem nevezett CD-n is ez volt a tapasztalat, aztan a rajta mellekelt igaz kicsit csunyacska tcl/tk feluleti "unixos verzio" meg 10 ev utan is fut. En csak azt mondom hogy egyesek kicsit rosszul ertelmezik hogy hol kene inkabb jobban ugyelni a kompatibilitasra ... En megertem e kernel fejlesztok allaspontjat hogy a kernel az a kernel abba miert rondit bele egy kulso ceg, mar eleve licensz politikailag is kifogasolhato modon. A user space mas, nyilvan azt futtatsz alatta amit akarsz. De ha pl mplayer-t felhozzuk peldanak, mi sem orultunk volna ha valami ceg azzal jon hogy hogy a fenebe merjuk az mplayer belsejeben levo (!) egyes komponensek kozotti API-t valtoztatni (ami azert megtortent ugye azert neha). Szoval azert nem olyan egyszeru ez aminek latszik, legalabbis szerintem.

Mondjuk "atlag" usernek persze ez mindegy, o ugysem erti az egeszet meg ugyis disztrib kernelt hasznal stb, tehat ez a vita amugy is kisse elvi jellegu.

Pontosan! Meg merem kockaztatni hogy a "Linux" felhasznalok tobbsegenek fogalma se lenne hogy mi a fenerol van itt szo :) Eppen ezert irtam is, hogy nyilvan kar kivetiteni ezt a problemat masokra is, mint akire tartozik: a fejlesztokre, akiknek teljesen jogos kivansaguk hogy a kernelbe ne piszkaljanak bele ***** closed source binary only cuccok ... En se orulnek ha az altalam irt programokba masik ilyeneket akarnanak beleeroszakolni :)

aham. peldaul az egy ***** nagy elony, hogy keptelenseg tisztessegesen olyan kodot irni, ami mondjuk jo esetben ket kernel ___al___ verzional tobbon lefordul ___es___ rendesen mukodik modositas nelkul.

ez elony? nem.

BARMILYEN elonyert felaldozhato BARMI egy jatek operacios rendszerben, amit jozsika szutykol pascalban a teli szunetben, de nem egy olyan OS eseten, amire joforman iparagak epulnek. jozsika OS-e nem ez a kategoria, a linux viszont igen. TCO-TCO-TCO, enterspajz-enterspajz-enterspajz; ismeros?

szanalmas, oncelu matyizas, ami jelenleg a linux kernellel tortenik, a sok szerencsetlen pedig eljenez hozza. gratulalok.

Nem erted, latom. A Linux kernel egy monolitikus kernel, eltekintve attol hogy "kulonleges" szerepkorben van a kernel EGYETLEN program! Semmi koze egy masik "kulso" teljesen mas elven felepulo dolognak hozza, ez ugyanolyan mintha egy XYZ GNU/GPL programba valaki egy binaris cuccot akarna beleeroszakolni "kivulrol". A kernelnek nem celja hogy belso komponensek kozotti APIt exportaljon harmadik fel szamara, erre a syscall-ok utjan elerheto API-t nyujtja ugye a user space fele. Sokan azt nem ertik meg, hogy a Linux kernel az egyetlen egyseg, nincs is ertelme arrol beszelni hogy a belso APIjai es absztrakcios retegei kozotti cuccokat kulso dologra felhasznald, ez mar a dologok "megeroszakolasa" es eleve nem is erre keszult az egesz.

Persze konstruktiv hozzaallas kapcsan, lehetne megoldast talalni azert erre is. Pl az nvidia drivereknel ugye van egyt "vekony" glue ami forraskodban is elerheto, de a "lenyeg" az nincs meg forrasban. Na ebbol kiindulva akkor az nvidia ne csak sajat maganak fejlesszen, hanem alljanak ossze, vagy valaki mas inditson egy olyan projectet ami letrehoz egy binaris szinten kompatibilis interface-t az ilyen projectekhez. Itt az is jo lenne, hogy akkor nem csak egyetlen ceg egyetlen "side projectje" (mert azert gondolom a win meg nagyobb uzlet, I mean tobb felhasznalo vesz nvidia kartyat aki windowst hasznal), ilyen modon tobb ember dolgozhatna rajta, es talan kinone azokat a gyerekbetegsegeket is ami miatt legtobben fujnak ra. Persze a legtobb dolgot jo lenne abbe a hlue layer-be is atvinni, hiszen kulonben ugyanott vagyunk ahol a part szakad ... Azaz az lenne a legjobb (de allitolag az nvidia ilyen, azt mondja magarol hogy unified driver core vagy mi), ha maga a driverben csak szigoruan az lenne ami valojaban mar OS fuggetlen es a vezerelt hw-hez kapcsolodik szorosan, minden mas erintekezesi pont jo lenne ha abba a layerben lenne. Szerintem ez meg egy ertelmes kozeput lenne ...

Ja, meg amugy azert nem vagyok annyira elvakult amilyennek latszom :) mert pl en is nvidia kartyat hasznalok binary only driverrel :)

Amugy ne feledjuk el a szelsoseges allaspontok elonyeit is :) Ha valaki valami nagyon szelsosegeset akar elerni (ami persze ugye elegge szubjektiv dolog), es annak csak 10%-at sikerul elerni, akkor az az illeto szamara esetleg kudarc vagy legalabbis nagyon mersekelt eredmeny, azonban annak szamara, akinek mar eleve tul szelsoseges lett volna a 100% lehet hogy a 10% az optimalis. Na ebbol azt akarom kihozni, hogy sok helyrol hallani hogy nincs ertelme a GNU/GPL-nek, "ugyis ellopjak", "csak a felhasznalok latjak karat ha nem lenne binary only driver" stb stb, viszont ha a multban nem kuzdottek volna annyira paran ez ellen akkor viszont most valoszinuleg szinte SEMMI nem lenne. Tehat torekedni lehet az elerhetetlenseg fele, ki lehet tuzni celnak, es lehetnek ertelmes eredmenyek igy mindenki szamara meg mindig. Nem emiatt kell feltetlenul kihorogni valakit szerintem.

> szerintem rugjak is fel nyugodtan ha ez BARMI elonyt jelent!

barmi elony = nem kell 1 honapnal elobbre gondolkodni.

> a kernel az a kernel abba miert rondit bele egy kulso ceg

Jelenleg eleg sok ceg rondit bele a linux kernelbe opensource modon. A tobbiek meg nem beleronditanak, hanem kulonallo modult fejlesztenek.

> A user space mas, nyilvan azt futtatsz alatta amit akarsz.

Ja, ha a libc-vel muvelnek ugyanezt, akkor gondolom boldog lennel. Esetleg havonta valtozna mondjuk a ps output, akkor biztosan remek shellscripteket lehetne irni.

( uid_228 | 2005. 11. 22., k – 20:52 )

Elnézést kérek, azt hiszem, hogy rossz helyen járok, akkor ez itt most nem a HUP? Mert nekem úgy néz ki a hozzászólások alapján, mint egy óvoda homokozója. :))))

"Nem erted, latom. A Linux kernel egy monolitikus kernel, eltekintve attol hogy "kulonleges" szerepkorben van a kernel EGYETLEN program!"

koszonom, hogy elmagyaraztad. tenyleg.

"Semmi koze egy masik "kulso" teljesen mas elven felepulo dolognak hozza, ez ugyanolyan mintha egy XYZ GNU/GPL programba valaki egy binaris cuccot akarna beleeroszakolni "kivulrol". A kernelnek nem celja hogy belso komponensek kozotti APIt exportaljon harmadik fel szamara, erre a syscall-ok utjan elerheto API-t nyujtja ugye a user space fele."

egy dolgot felejtesz el: a linux kernel ugyan monolitikus, de lehetoseg van a funkcionalitas "modositasara" (ertsd: funkciok hozzaadasara/elvetelere) dinamikusan, futasidoben, KERNEL MODULOK segitsegevell, ellentetben a klasszikus, teljesen monolitikus kernelekkel, amilyen peldaul a mai napig a hp-ux, de talan meg az aix is.

"Ssokan azt nem ertik meg, hogy a Linux kernel az egyetlen egyseg, nincs is ertelme arrol beszelni hogy a belso APIjai es absztrakcios retegei kozotti cuccokat kulso dologra felhasznald, ez mar a dologok "megeroszakolasa" es eleve nem is erre keszult az egesz."

ezt kifejtened?

In article <42.58211@c.hup.hu>, zsirfeka wrote:
> _"Ssokan azt nem ertik meg, hogy a Linux kernel az egyetlen egyseg, nincs
> is ertelme arrol beszelni hogy a belso APIjai es absztrakcios retegei
> kozotti cuccokat kulso dologra felhasznald, ez mar a dologok
> "megeroszakolasa" es eleve nem is erre keszult az egesz."_
>
> ezt kifejtened?

Ilyen az, amikor a GPL virus megfertozi a kodot :)

--
Gabucino

> Nem erted, latom.

Mindenki erti mirol van szo, es mit akarnak elerni a kernelfejlesztok (pontosabban par ember kozuluk), de ez nem jelenti azt, hogy ez a helyes ut.

> belso APIjai es absztrakcios retegei kozotti cuccokat kulso dologra felhasznald

Ha valoban teljesen monolitikus lenne, akkor nem kene egyaltalan kiexportalni semmit mert nem kene modult betolteni :)

Nem ertem miert artalmas a binaris modul, kinek okoz fejfajast a gyarton kivul.

> Szerintem ez meg egy ertelmes kozeput lenne

Akkor kiadjak a felet opensourceban, fele binaris. Ez mitol jobb? Ugyanugy binaris driver van a kernelben, jon a tainted malicsuszmano, rosszneked, vegedvan, megeszi a kondenzatorod az instabil kernel. Helyette sokkal jobb a licenszben levo tiltas ellenere binaris drivert reverse engineerelni, es belerakni a mainline kernelbe az eredmenyet, mert az sokkal legalisabb mint a binaris driver.

> en is nvidia kartyat hasznalok binary only driverrel :)

pff miert? :)

A kernel modulok meglete vagy nemlete nem valtoztat semmit, az kb annyit tesz mint a dlopen() hasznalata user space-ben, runtime linking. De a kulcskerdes itt TENYLEG az, hogy ez semmit nem valtoztat, nem is csoda hogy minden configolhato: fixen a kernelbe forditod vagy modulba, ez is mutatja hogy ez csak implementacios sajatossag, valojaban nagy kulonbseg nincs, ha egy modul be van toltve akkor ugyanugy a kernel resze, nem egy kulonallo egyseg, tehat nem egy mikorkernel architektura, ahol a legtobb dolog valojaban kulon "process" amelyek egymassal kommunikalnak, de jol szeparaltak is egyben. Attol hogy valami modulban van nem valtoztat azon hogy itt "tul szoros" az integracio a kernel tobbi reszevel.

A "megeroszakolast" ugy ertem, hogy pl az nvidia eseten letrehoztak egy glue layer-t hogy be lehessen nyomoritani azt a binary only cuccot. Ami alapvetoen nem lenne baj ha nem probalna ezt mindenki maskepp csinalni, hanem valami konszenzus lenne, es akkor lenne egy stabil driver API. Ugyanis a linux kernel belso API-ja az szandekosan nem valtozatlan hiszen a kernel az egy egyseg, amin "nem illik" surrun valtoztatni az ugye pl a user space fele nyujtott API.

Amugy persze lehet azt mondani hogy a Linux kernel design-ja alapvetoen rossz. Viszont ha elfogadjuk hogy ez van, akkor ebbol kovetkezik hogy nem is cel es nem is lehet cel forras szinten se kompatibilitas verziok kozott az egyes kernel subsystemek kozott, hiszen nem is cel ezt tartani!

Miert? Attol valami egy program hogy pl egy lib-hez linkelodik, nem? Ekkor persze ki vannak egyes symbolumok exportalva stb, de a libet nem tekinted kulon programnak, eleve ugye kulon kontextusa sincs, gyakorlatilag osszelinkelodik a programoddal es "egykent" viselkedik. A linux kernel eseten kisse erdekes a dolog, de a kernel modulok gyakorlatilag felfoghatoak hasonloan, a kiexportalt szimbolumok gyakorlatilag analogiaja annak, amikor egy program meghatarozza hogy melyik symbol van kiexportalva, attol az nem kulon egyseg ... Meg ezen miert mulna valami? Legtobb

dolog fordithato fixen kernelbe meg modulba is, ez mutatja, hogy gyakorlatilag nincs alapveto elvi kulonbseg annyira. Persze nvidia drivert nem lehet kernelbe beleforditani, de ennek oka, mindossze annyi, hogy licenszproblemak miatt talaltak ki a "modul only" megoldast, ennek elsosorban nem technikai oka van ahogy en latom.

A masik dologgal meg arra akartam ravilagitani, hogy amennyire en elkepzelem legalabbis a legtobb kernel developernek az faj (leszamitva az onerzetet :), hogy egy binary cucc sokat galibat tud okozni, es ha vmi problema lep fel, nehez megallpitani hogy mi okozza, hiszen "nem latnak bele" a binary only driver-be. Es bizony, ha terjednek a binary only driverek hasznalata akkor gyakorlatilag egyre szukul a kernel tesztelesenek lehetosege, mert problema eseten ilyenkor nem egyertelmu az ok esetleg. Ergo csokken a megnizhatosag, mert maguknak a kernel fejlesztoknek sincs lehetoseguk atlatni a reportolo ermber rendszeret mivel nincs birtokukban az a tudas ami a binary only belso mukodesevel kapcsolatos (de most komolyan, egy atlag "modern" gnu/linux disztribben nezd meg milyen aranyban van binary only driver, szerintem eleg sok, es ilyen esetben a bugreportok mindig problemasak lehetnek). Persze utopisztikus lenne, ha csak open source driverek lennenek, ezert probalkoztam azzal a gondolattal eljatszani, hogy akkor legalabb EGY ilyen glue reteg lenne ami viszont legyen jol megirva es minnel tobb OS specifikus cucc keruljon at oda, ezzel javirtva valamit a helyzeten.

Lehet hogy total rossz uton jarok, persze, csak probaltam itt magamban kitalalni valamit ...

"Ugyanis a linux kernel belso API-ja az szandekosan nem valtozatlan"

persze, vegulis lehet erenyt kovacsolni barmibol.

"Amugy persze lehet azt mondani hogy a Linux kernel design-ja alapvetoen rossz."

nem, a fejlesztesi modell es a core fejlesztok hozaallasa rossz.

"nem is lehet cel forras szinten se kompatibilitas verziok kozott az egyes kernel subsystemek kozott, hiszen nem is cel ezt tartani!"

aham, orulok. ez is elony?

tovabbra sem ertem ezt a "ha binaris a driver, akkor biztosan *****, ha nyilt forrasu, akkor biztosan jo" elmeletet, amit egesz nap nyomattok. biztos ez ia a lunikszenterspajz resze.

Hat, ennyire tenyleg nem fekete-feher, valamelyik hozzaszolasomban leirtam a velemenyem, amit en kihamoztam az idok soran ebbol a temabol (mert ugye ez nem ujkeletu dolog): arrol van szo, hogy minden software-t kell tesztelni, hibat kell javitani. Ha tfh Linux felhasznalok (-bol azok akik egyaltalan bugreportolnak valami ertelmeset) 99% binary only drivert tartalmazo kernelt futtat, akkor a hiba nyomkoveteset/kideriteset/vizsgalatat neheziti - ha nem lehetetlenne teszi - az a teny hogy maguk a kernel developerek sem lathatjak a teljes rendszer mukodeset! Tehat nem lehet tudni , hogy nem a bin driver okozta-e a gondot, kozvetlen v kozvetve mert nincs meg a forrasa, meg semmi ami ehhez kene! Elgondolkoztam, hogy lehet, Microsoft NDA-k alairasaval megkapja a legtobb driver forrasat a gyartoktol, akkor persze "neki konnyu", de az open source eseten erdekes elvi problema lep fel hogy meg a rendszer "letrehozoi" sem tudnak mit tenni ilyenkor hiszen egy "alien" ;_) van a rendszerben ami egy fekete doboz szamukra is! Azaz elvettek a lehetoseget attol hogy az open source rendszer teljes mukodeset at tudjak latni, mert ok erre kepessek is lennek esetleg, megha nyilvan atlag r=1 usernek ez mind1. Az manapsag is lathato problema, de mi lesz ha kvazi bin driver nelkul el sem indul mar egy atlag gep annyi ilyen kell majd? Akkor komoly gond lesz itt ebbol, ha belegondolunk ... Na, ezzel csak azt akarom mondani hogy _szerintem_ ez (is?) lehet az oka ennek a flamewar-nak.

> nehez megallpitani hogy mi okozza

Nem tudom eszrevetted-e mar mi tortenik akkor amikor tainted kerneles bugreport erkezik a kerneldeveloperekhez...

> nincs birtokukban az a tudas ami a binary only belso mukodesevel kapcsolatos

Igy van, telibe is sz*rjak ezert, ez igy is van jol, semmi kozuk hozza, menjen mindenki visitani a gyartohoz, vagy hasznaljon opensource drivert.

> egy atlag "modern" gnu/linux disztribben nezd meg milyen aranyban van binary only driver, szerintem eleg sok.

En nem vettem eddig eszre.

Nost akkor tovabbra sem latom a hatranyat. Bizonyos esetben a gyartonak elonye szarmazik abbol, hogy opensource a driver, bizonyos esetben pedig nem, ekkor nem ad ki semmit (ez a ritkabb).

> hogy akkor legalabb EGY ilyen glue reteg lenne...

Igen kiraly lenne, csak olvasd el mr stablefoisten elozo vicces megmozdulasat, amiben kifejti velemenyet a driver apirol :)

Mint irtam, folosleges elmagyarazni mit akarnak, mert en is latom. Gondolom a glue reteget meg nem azert vetetted fel mert teljesen egyetertesz gregbacsival :)

En itt ugy ertem hogy TECHNIKAI ertelemben nem valtoztat semmit a modul / nem modul kerdes, azaz hogy attol meg ugyanugy monolitikus kernel, hiszen egy context az egesz, itt nem jogi es licensz elteresre gondoltam ahol tenyleg van kulonseg.

Amugy Linuxban vannak nem monolitikus kernelre jellemzo egy-ket dolog, pl kernel thread az amolyan hibrid cucc, scheduler kulon processnek latja de nem teljesen az, vagy pl a FUSE, ahol ugye egesz mikro-kernel arch. gyanus modszerrel mukodik a dolog, stb, de a modul kezeles az pont nem illik ide a sorba: attol nem lesz kevesbe monolitikus a Linux kernel, ill nem ettol lesz nem az :)

Szerintem meg sok, pl egesz sok embernek van nvidia kartyaja pl nekem is (megjegyzem azert, mert csak linuxom van, es normalis 3d teljesitmenyt nyujto kartya amihez van legalabb altalaban mukodo normalis driver az az nvidia, megha ez binary only is, sajnos vagy nem sajnos ...), dehat ATI-t is ide lehetne sorakoztatni. Es itt megint a "szelsoseges nezopontok haszna" kerdes is felmerul: ha nem kuzdenenek egyesek foggal korommel a binary only driverek ellen akkor meg tobb lenne ma, es meg kevesebb lenne talan az olyanok szama akik megnyitottak a kodot, adtak doksit a fejlesztoknek vagy hasonlo ... Ez ugyanaz, minthogy vizsgara sem a kettest kell megcelozni, mert ugye ha az nem sikerul, akkor bukta. Igenis meg lehet celozni az otost is akar, es ha csak harmas lesz, akkor meg mindig atmentel ;-)

Az nvidia driver egy, az ati megegy. Ez a ket legismertebb. A tobbi nagyon sokat nem latom, van meg ugyan 1-2, de azok eleg ritkan hasznalt cuccok. Ertem az aggodalmad, es mondjuk azt, hogy igen a linux valoban egy olyan dolog lesz, ahol erre nagyon odafigyelnek, greg jol betolja a patchet, tok jogos, legyen minden feher (nem lesz akkor sem, de errol most feledkezzunk meg). Ezzel egyutt elfelejthetik vilaguralmi terveiket, mert ez lathatoan nem fog mukodni. Nem igy mukodik az enterspajz, ahova olyan gozerovel probalnak betorni. Pl. az nvidia soha a budos eletbe nem fog kiadni olyan drivert amiben a driver minosege nagysagrendi sebessegkulonbseget eredmenyez, hiszen elveszitene elonyet a versenytarsakhoz kepest. Az nvidia az eredmenyeit nem csak hwtervezoinek, hanem a driverfejlesztoinek is koszonheti. Ugyanugy nem fog pl egy normalis zartforrasu cluster fs-t fejleszto ceg kiadni a cuccait, hiszen ebbol el, fogja es leveszi a linuxot a supportalt rendszerek listajarol, mert maskepp bezarhatna a boltot. Nem minden ceg van felkeszulve az rms altal josolt szolgaltatasalapu modellre, van amelyik soha nem is fog ilyen modon mukodni. Es meg egy aprosag: az hogy egy ceg kiad opensource drivert, meg nem eleg. Koszonhetoen ennek a rohanasnak, folyamatosan maintainelni kell, ha nem teszi kidobjak a driverevel egyutt, mert eppen nem fordul vicces morton legujabb breakeljuk-a-multhavi-mastbreakelo patchevel. Mikozben arrol beszelnek, hogy megyunk az enterspajzba, beintenek az enterspajznak. Lehet keresni kifogasokat miert rossz nekik, de a valodi ok az, hogy elszalltak maguktol.

( budee | 2005. 11. 23., sze – 11:40 )

Epp most szembesultem ezzel a problemaval. SATA vezerlot kellett vennem, volt 4 lehetoseg, az egyik baromi draga volt, kiesett, 2-hoz binaris driver volt, igy azt valasztottam amihez van a kernelben tamogatas. A valasztasom csakis driver alapjan tortent, mivel ha a masik kettohoz van opensource driver akkor azok kozul valasztok, mert azok jobbak voltak. Ha nem lett volna driver egyikhez se, akkor nem veszek SATA vezerlot, es megoldom valahogy mashogy a dolgot.

Amugy nem ertem a hozzaszolasokat, miert lenne az rosz ha minden hardverhez lenne nyilt kodu driver? Ezzel mi csak nyernenk.

( rigidus | 2005. 11. 26., szo – 12:11 )

Szerintem ez az egesz flem tok felesleges volt. Legalabb annyira felesleges mint az osszes tobbi.

Szerintem aki egyetert ezzel, az hasznalni fogja, aki nem annak pedig van meg jopar lehetosege a BSD rendszereknel. A Trey sincsen tole elragadtatva ha beleugatnak a portal vezetesebe es en utolagosan vegiggondoltam az erveit, amibe ma mar egetertek vele, korabban nem igy volt. Ez az o projektje, akinek nem tetszik szetnez mashol. Ez a Linux kernelre is igaz.

Ennyi...

Nos, ezert is mondtam hogy a szelsoseges allaspont elonyei :) Torekedni kell az utopisztikus elerhetetlen minden open source stb tema fele, es ha egy kicsit osszejon az mar nagy nyereseg azert sok embernek. Viszont ha nem nyomnak ennyire, ha Greg nem hivna fel a nep figyelmet, senkit nem erdekelne akkor lehet mar reg eltunt volna az egesz open source ... De ami a realitasokat illeti: tokeletes megoldas ugysincs, ez teny, nem is lehetne kiolni hirtelen minden closed source drivert (illetve lehet, aki akar most is tehet igy sajat gepen vegulis), de torkedni kell azert arra hogy minnel tobb ceg vegye eszre hogy a legjobb megoldas ha infot ad ki fejlesztoknek vagy meg jobb ha forrast is nyit esetleg :) Persze ettol mindenki nem fog, az is igaz ...

( uid_2813 | 2005. 11. 22., k – 13:12 )

"Ha Te vagy céged zárt forrású kernel modulokat használsz, napjaid meg vannak számlálva." - írja Greg.

Vagy a linuxe?

( sz332 v | 2005. 11. 22., k – 13:13 )

Most ennek mi értelme van? Az adott eszközök elsősorban úgyis a nagy disztrókon fognak futni, azokon lesznek letesztelve, azok meg, ha ilyen eset lenne, szépen kiveszik ezt a részt a kernel forrásból. (mint closed driver support feature) :) Senki nem vonja kétségbe, hogy jobb, ha egy driver open source, de vegyük már észre, hogy az egész az üzletről szól. Lehet, hogy olyan kereszt-licenszelések, szabadalommal (fujj) védett eljárások vannak a háttérben, ami miatt nem lehet kirakni open source-ba a kódot...

( shusaku | 2005. 11. 22., k – 13:24 )

és akkor csodálkozunk, hogy sokan miért nem veszik komolyan a linuxot....

( zsirfeka | 2005. 11. 22., k – 13:34 )

kene egy "szanalmas" kategoria es g.k-h megmozdulasait a tovabbiakban oda postolni. persze a fun is megfelelo lehet.

ideje lenne mar, hogy felpofozza valaki ezeket a ***** idiotakat.

barmelyik opensource oprendszer hamar tonkremenne, ha elterjednenek a zart forrasu driverek.

Az M$-nak sok penzt megerne, hogy lefizessen driver programozokat, hogy instabilla tegyek a rendszert. a driverek a monolitikus kernel reszei.

GKH modszere nem a legjobb, de valami kellene, hogy visszaszoruljon a zart forraskodu driverre valo atalas tendenciaja.

( wolphie | 2005. 11. 22., k – 13:36 )

> hogy magyarázná meg a főnöknek/ügyfeleknek, hogy miért nem működik az adott eszköz Linux alatt.

Gondolom ugy hogy elmondja, megint elszallt a kerneldeveloperek agya :)

Egyebkent meg az ugyfelet nem fogja erdekelni miert, szamara csak az latszik, hogy nem mukodik -> tehat nem biztos, hogy szamara a linux a megfelelo valasztas. (amennyiben szuksege van a binaris driver altal nyujtott funkciokra)

"barmelyik opensource oprendszer hamar tonkremenne, ha elterjednenek a zart forrasu driverek."

ezt megindokolnad? ertelmesen. eroltesd meg magad, kerlek.

"Az M$-nak sok penzt megerne, hogy lefizessen driver programozokat, hogy instabilla tegyek a rendszert. a driverek a monolitikus kernel reszei."

el kene menned egy pszichologushoz, nem? vagy inkabb hagynod kene a francba ezt az informatikia-dolgot.

neha gondolkodhatnal, mielott ekkora baromsagot leirsz.

"de valami kellene, hogy visszaszoruljon a zart forraskodu driverre valo atalas tendenciaja."

miert, ez most a tendencia?

"barmelyik opensource oprendszer hamar tonkremenne, ha elterjednenek a zart forrasu driverek."

ezt megindokolnad? ertelmesen. eroltesd meg magad, kerlek.

Ugyan nem vagyok anr, de megprobalok valaszolni a kerdesedre.

Fokebb lkml-rol ideznek, tehat az itt elhangzott dolgokat nem en talaltam ki.

As long as they don't need to put binary junk in the kernel, they can

keep the binary junk in userland, where it belongs. That is at least

acceptable and legal, even if it's not a great situation.

Szoval ha valaki binaris driverekkel akar ganyolni, megteheti, de ne a kernelbe rakja bele a szarjat. Erre a szituacio jo pelda az ndiswrapper.

Es a kerdesedre a valasz:

The problem is they load these multi-megabytes blocs that want to hook

into SMM BIOS interrupts, ACPI, VM, etc... all over the place and do all

sort of junk in your kernel. Say goodbye to any kind of stability and

maintainability of a kernel loaded with that crap.

....

But the real reasons are elsewhere anyway. They don't wnat to opensource

because they don't want to open the gazillion security holes in their

stuff (afaik, the binary drivers make absolutely no verification of the

command streams passed from userland, you can make the card do whatever

you want from any user context, including arbitrary DMA to/from system

memory),

Innen ideztem:

http://thread.gmane.org/gmane.linux.kernel/351091

Raadasul ehhez hozzajon meg, hogy szerintuk illegalis binaris drivert loadolni a kernelbe. Oldjak meg ugy, ahogy az ndiswrapper, vagy csinaljanak opensource drivert.

Egyebkent a fo gond nem is az ati/nvidia parossal van (mivel a desktop linux elenyeszo a server terulethez kepest), hanem az SCSI es SATA binaris driverek teruleten. Ahol a stabilitas nagyon is fontos tenyezo, amit binaris drivereknel nem lehet garantalni.

Es a server teruleten meg penz is van imho a linuxban (ez mar maganvelemeny).

Udv,

Khiraly

attol mindenkeppen jobb, mint ha egyaltalan nincs driver.

es az is elofordulhat am, hogy nem azert nem ad ki nyilt forrasu drivert a gyarto, mert ko"***** (vagy mert lefizette a microsoft, MUHAHAHAHA), hanem azert, mert olyan licenszek/megallapodasok/akarmi koti, amik _nem_teszik_lehetove_, hogy binaris drivert adjon ki, barmennyire szeretne is.

egyebkent pedig meseld mar el, miert lennenek tele a rendszereim ilyen-olyan binaris driverekkel azokon kivul, amikre szukseg van? vagy ez mar bonyolult?

Dontse el a juzer, hogy hasznal-e a binaris drivert vagy sem. Ha neki ez jo (igen, pl nagysagrendekkel jobb mint az opensource ati/nvidia driver), akkor az o dolga, hogy a rendszer "instabil" lesz. Ha varnia kell egy evet az o baja. Sokkal jobb lesz majd, hogy a kernel forras melle az binaris gyartok is csomagolnak majd "vicces" kernelpatchet, ami lehetove teszi szamukra, hogy binaris modult tudj betolni?

A zart forrasu alternativak megolik a nyilt forrasu kezdemenyezeseket. Tehat imho meg artanak is;)

Nezd meg a bcm43xx projektet. Ok a wifi vezerlokben elterjedt Broadcom chippekhez probalnak opensource drivert irni. Mondhatnad, hogy irjanak, meg akinek ideje van varja ki. De ha megnezed, hogy kik is fejlesztik, szinte az *osszes* fejleszto PPC platformrol jon (apple gepek foleg).

Pedig x86 alatt se kapsz teljes erteku kartyat az ndiswrapperen keresztul (pl. nem tudod hasznalni a kismet-et). De ugy nez ki, hogy x86 alatt levoket nem erdekli (elfogadjak a felmegoldasokat).

Szoval ha nincsenek rakenyszeritve az emberek, akkor nem fognak drivert irni.

Egyebkent a videokartya-driverek a legkisebb gond imho (ott mar ugysincs mit tenni).

"Szoval ha valaki binaris driverekkel akar ganyolni, megteheti, de ne a kernelbe rakja bele a szarjat."

tehat: a binaris drivert irok mind balfaszok, akik ***** kodot irnak, ellenben az opensourceistenek kivalo koderek?

"Raadasul ehhez hozzajon meg, hogy szerintuk illegalis binaris drivert loadolni a kernelbe. Oldjak meg ugy, ahogy az ndiswrapper, vagy csinaljanak opensource drivert."

es amit nem lehet "ugy" megoldani? a "vagy csinaljon opensource drivert vagy dogoljon meg" hozzaallast pedig nem kommentalom, megtettem mar korabban (ebben a threadben is), keresd meg, ha erdekel.

" hanem az SCSI es SATA binaris driverek teruleten. Ahol a stabilitas nagyon is fontos tenyezo, amit binaris drivereknel nem lehet garantalni."

miert? ki nem tudja garantalni? greg kroah-hartman? andrew morton? irjon a gyarto tisztesseges kodot.

> jo pelda az ndiswrapper

Ndiswrapper:

This project implements Windows kernel API and NDIS (Network Driver Interface Specification) API within Linux kernel. (tehat ez egy kernelmodul)

Ott a varazsszo: API. Ha lenne esetleg egy kernel api, a binaris "szarokhoz", akkor nem kene annyit beleganyolniuk. Es akkor most a teljesitmenyproblemaktol eltekintettunk, amit a userspaceban futtatas okozhat.

broadcom-os wifi vezerlo. Ez lemaradt.

De irhatok meg media kartya olvasot(5-in-1 texas instrument), winmodemet is (szerencsere ez mar kihalofelben)

Hmm, alig maradt olyan cucc a gepbe, amihez opensource driver kellene;) (bill, eger)

Szerinted az igy kapott geped ugyanolyan stabil lesz?

Wake up.

"A zart forrasu alternativak megolik a nyilt forrasu kezdemenyezeseket."

valamint

"Szoval ha nincsenek rakenyszeritve az emberek, akkor nem fognak drivert irni."

ez egy baromsag szerintem es cafolod is vele az open source nagyszeruseget bizonyito teteleket. ezek szerint az open source driverek csupan azert vannak, mert a userek rakenyszerultek, hogy irjanak sajat nyilt forrasut?

ha az open source olyan jo (sok esetben igen), akkor miert olne meg egy _lehetoseg_ barmit is?

> Szoval ha nincsenek rakenyszeritve az emberek, akkor nem fognak drivert irni.

Ha nincs infojuk az adott hardwarerol vagy, a firmware licensz nem engedi meg, akkor egyhamar nem is fognak. Elfelejted, hogy a keresztbe licenszelt dolgokat nem adhatja ki akarmelyik ceg csak ugy. A legtobb drivert nem azert nem adjak ki mert nincs kedvuk hozza, hanem azert mert tonnanyi licenszelt technologiat hasznalnak bennuk, aminek a jogaival nem ok rendelkeznek.

"Szoval ha valaki binaris driverekkel akar ganyolni, megteheti, de ne a kernelbe rakja bele a szarjat."

tehat: a binaris drivert irok mind balfaszok, akik ***** kodot irnak, ellenben az opensourceistenek kivalo koderek?

Nem ugyanugy fejlesztik, mint a kernelt. Igy a minosege se lesz ugyanolyan (lehet jobb v. rosszabb). Raadasul a kernelfejlesztoknek kellene a binaris driver irokhoz alkalmazkodni ...

Gondolom megoszlanak a velemenyek, hogy egy feleves multtal rendelkezo taiwani ceg (aki csak licenszeli a gyartasahoz szukseges technologia), ir egy drivert, az jobb minosegu lesz, mint a linux kernelhez irt driver. (amit jobb esetben tobb eves kernelfejlezstesi multtal irnak bele).

Az a gond, hogy ami binaris drivert en hasznaltam, mindegyik bugzott meg. Nemelyikhez van workaround, de a tobbi kidebugolhatatlan. Opensource drivernel is volt mar, hoyg bugot talatam, de azt javitottak (miutan reportoltam). De a mouse-pushereknek ezt lehet magyarazni;)

Egyebkent a binaris driverek a bsd-knek valok, lehet azt hasznalni;) (ez mar poen akart lenni)

te amugy mirol beszelsz?

egyebkent szerinted miert alapveto tetel az, hogy nem lesz "olyan" stabil? (milyen stabil?)

egyebkent szerintem ne feszegessuk annyira a jelenlegi mainline stabilitasat, mert tud az instabil lenni binaris driverek nelkul is (igen, szerverrol is beszelek).

nezd, ha nekem fontos, hogy open source drivereket hasznaljak (mert valoban jobb/szebb/gyorsabb), akkor olyan termeket valasztok, amihez van ilyen driver. ha pedig nincs, akkor igy jartam, de nem fogok valamit kapasbol elutasitani csak azert, mert a rohadekok nem adtak ki nyilt forrasu meghajtot hozza.