Ingyenes Linux driver fejlesztés hardvergyártó cégek részére

Kernel

Greg Kroah-Hartman blogjában egy bejelentést tett, miszerint a Linux kernelfejlesztői közösség kész ingyen bármelyik cég bármelyik hardveréhez driver-t fejleszteni. Ezután a cégeknek nem kell dokumentációt bújniuk, nem kell mintakódokat elemezniük, hogy linuxos driver-t készítsenek. Mindössze annyi közreműködés kell a cégektől, hogy azok adják át az eszközeik működési dokumentációját, vagy egy kapcsolattartó mérnök e-mail címét, aki felmerülő kérdések esetén választ tud adni azokra. Esetleg néhány eszköz is elkél a driver-ek hibakereséséhez.

Mit kap ezért cserébe a cég?

A cég cserébe komplett és működő meghajtóprogramot kap az eszközéhez, amelyet a fejlesztők be is emelnek a mainline Linux kernelbe. A driver-t a fejlesztői közösség valamely tagja fogja megírni (több mint 1 500 fejlesztő, akiknek száma egyre nő). A driver automatikusan bekerül az összes Linux disztróba, beleértve a "vállalati" verziókat is. A cégnek nem kell foglalkoznia a driver-t érintő kernel API változásokkal, mert azokat a fejlesztők lekövetik, és a driver-t naprakész állapotban tartják. A driver működni fog az összes Linux kernel által támogatott CPU architektúrán. A driver-t az eredeti fejlesztők fogják e-mail-en keresztül támogatni, és a vállalati Linux disztrók, akik elvégzik ezt a támogatást az ügyfeleikkel kötött szerződéseik keretein belül.

Ha a cég aggódik az eszköze körül levő NDA problémák miatt, akkor a fejlesztők vállalják, hogy az OSDL/TLF Tech Board-jával közösen összehoznak egy jogi keretrendszert, amelyen keresztül a cég kommunikálhat a közösség fejlesztőjével, és biztos lehet benne, hogy minden, az NDA-kban megfogalmazott feltételnek eleget tesznek (nem sérülnek a cég NDA-s kötelezettségei).

A cég fejlesztői ezután többet dolgozhatnak más operációs rendszerek driver-ein, és nem kell a linuxos fejlesztésekkel foglakozniuk, mert az azzal járó munkát a közösség átvállalja tőlük. A cég viszont kiírhatja termékére, hogy "supported on Linux".

Az ajánlat minden típusú eszközre érvényes, legyen az egy USB-s pendrive, nagysebességű hálózati adapter, vagy egyéb bővítőkártya. Ha egy cég megépíti az eszközt, a fejlesztők megcsinálják hozzá a drivert.

A bejelentés itt.

( trey | 2007. 01. 30., k – 15:48 )

Nagyszerű felajánlás. Remélem sok cég fog vele élni. Ha nem, akkor sem mondhatják, hogy a Linux kernel fejlesztőin múlt.

--
trey @ gépház

( MrCrowley | 2007. 01. 30., k – 16:15 )

"komplett és működő"

Nagy örömmel töltötte volna el szívemet GKH ha mondjuk a "megfelelően működő" kifejezést használta volna. Vagy csak nekem vannak rossz emlékeim? :) :(

( Pontscho | 2007. 01. 30., k – 16:16 )

Je', valami ertelmes dolog.

---
pontscho / fresh!mindworkz

( -Mr- | 2007. 01. 30., k – 16:17 )

Na! Lehet ezt kevésbé fröcsögősen is. Ez a hozzáállás a cégeknek is jobban bejön szerintem, mint a korábbi felszólítások, hogy "márpedig speckót ide nekünk, mert különben irgum-burgum..."

-Mr-

( sz332 v | 2007. 01. 30., k – 16:20 )

Remélem a Xerox kapva kap az alkalmon, és végre lesz driver a Xerox
one touch easy 4800-as scanneremhez... (pedig usb-s a drága...)

Xerox hozzáállása:

"Hello Zsolt,

We recommend that you contact customer support directly by calling
1-800-648-0410 or visit:
http://www.xeroxscanners.com

Thank you,
Chris
Webmaster Mail Team
Xerox
http://www.xerox.com"

xeroxscanners.com oldalán nem találtam direkt email címet, a scannerem
mintha meg nem is létezne...

( Oregon (nem ellenőrzött) | 2007. 01. 30., k – 16:22 )

nagyon jo kezdemenyzes. ha a bejelentesbol hianyzik, akkor en is nagyon hianyolom:

1. hatarido, hogy meddig lehet jelentkezni erre a felajanlasra (nem termekkel, hanem ceggel)
2. mondjuk csak az elso n ceget fogadjak ebben az akcioban

ez a ket pont azert kell, hogy erezzek, hogy kimaradnak valamibol ami k.jo nekik.

Inkább fejlesztőkapacitásbeli limitnek látnám értelmét. De arra meg nehéz mutatószámot írni, mert egyik fejlesztő ilyen hw-hez jó, a másik olyanhoz, meg vannak olyan hw-k, amihez többféle szakterületről is kell fejlesztő.

( KG | 2007. 01. 30., k – 16:22 )

Reméljük, gyorsan nő majd a száma azoknak a gyártóknak, akik élnek vele!

( numen v | 2007. 01. 30., k – 17:01 )

és eljövend a Kánaán... tény és való, jó ez a dolog, de ha eddig kiadta a speckókat a cég, nem ugrottak rá a kernelfejlesztők? valami miatt olyan érzésem van, hogy ez nagyjából ugyanaz, ami eddig volt...
másik kérdés, hogy miért rakná ki mostantól a cég a termékére, hogy supportálja a linux? eddig is kismillió dolog van, ami működik, mégsincs ráírva. mintha nem lenne érdekük megcélozni ezt a szűk réteget.
_________________________________________
Valódi paraszt vagyok. Csak előre tudok lépni, nem azt ütöm le, aki velem szembenáll, és ha nincs tovább, megváltozom.

( szdl | 2007. 01. 30., k – 17:05 )

Éljen!

Remélem élnek is a felajánlással..

( Chip | 2007. 01. 30., k – 17:31 )

Nagyon jo kezdemenyezes! Sok sikert hozza!
Vajon az nVidia meg az ATI^H^HMD is elni fog a lehetoseggel? :)

( Andrei | 2007. 01. 30., k – 17:41 )

Node eddig is ez volt a helyzet implicite... Ahol volt doksi, ott megcsinaltak a fejlesztok a drivert.

Persze igy vallalnak bizonyos garanciakat, ami valoban szep gesztus.

Eddig semmilyen ígéret nem volt. Ha volt doksi és _valakit érdekelt_ a téma, akkor megcsinálta, ha volt ideje karbantartotta, ha letiplizett, akkor a driver elavult, majd esetleg ki is került a fából. Most meg az én értelmezésem szerint garanciát vállalnak arra, hogy ha valaki hozzájuk fordul, akkor:

- megcsinálják a driver-t
- karban is tartják

Szerintem ez különbség.

--
trey @ gépház

Nem olvastam el a linkelt cikket, de azért vannak kérdéseim:
- gkh pontosan kinek a nevében nyilatkozott?
- mi az a garancia, hogy ezután megcsinálja valaki, akár korrektül, akár nem? Fegyvert fog az 1500, világ számos pontján szétszórt, tizeniksz cégnek dolgozó, vagy csak hobbi linugz baszkurátornak a fejéhez és ha nem hajlandó betartani az *Ő* ígéretét, fejbelövi?

"- gkh pontosan kinek a nevében nyilatkozott?"

Elolvasva az ajánlatot, nekem úgy tűnik, hogy minimum a saját, az Open Source Development Labs (tagjai: Alcatel, Cisco, Computer Associates, Dell Computer Corporation, Ericsson, Force Computers, Inc., Fujitsu Ltd., Hitachi Ltd., HP, IBM, Intel, Linuxcare, Inc., Miracle Linux Corporation, Mitsubishi Electric, MontaVista Software, NEC Corporation, Nokia, NTT Data Intellilink, Red Hat, Sun Microsystems, SuSE Linux AG, Timesys, Toshiba Solutions, Transmeta, Turbolinux, Ulticom, Unilever, VA Software, Wind River, stb. - friss taglista itt (csupa szar név :)) és a Free Standards Group nevében (az utóbbi kettő egyesülni szándékozik, és a kettőből létrejön a The Linux Foundation (OSDL + FSG = TLF).

"mi az a garancia, hogy ezután megcsinálja valaki, akár korrektül, akár nem? Fegyvert fog az 1500, világ számos pontján szétszórt, tizeniksz cégnek dolgozó, vagy csak hobbi linugz baszkurátornak a fejéhez és ha nem hajlandó betartani az *Ő* ígéretét, fejbelövi?"

Nyilván én nem tudom, esetleg tippelni tudok arra, hogy ha bevállalják, akkor vagy a) megíratják valakivel a közösségből ingyen, ha ez nem megy b) megíratják a közösségből valakivel pénzért. A TLF mögött álló cégek gondolom ezt finanszírozzák.

Gondolom ezt az akciót megbeszélések és tervezések előzték meg. Ha nem így van, akkor lehet, hogy beivott és annak az eredménye :)

--
trey @ gépház

Az ingyenfejlesztésre garanciát nyilván nem lehet vállalni, tehát ez kilőve. A pénzért fejlesztés rendben van, de ezen meg csodálkoznék. Jellemzően a Microsoft sem csinál ilyet, bár ő lehet, hogy nem azért, mert x milliárd dollárba kerülne évente, hanem azért, mert a gyártók úgyis megírják, ami a Linux esetén úgy látszik még hagy kívánnivalót maga után.

pl. közös tervezés, annak dokumentálása, majd utána a kódolási/tesztelési/validálási feladatok szétszedése és kiosztása. Ha bizonytalan a helyzet, akkor a feladatrészt több embernek is oda kell adni és az előbb vagy jobb minőségben elkészült eredményt felhasználni, a másikat meg elrakni emlékbe. 1500 fejlesztő már hatalmas közösség, lehet rá alapozni.

( Hunger | 2007. 01. 30., k – 17:49 )

Nem értem mi ebben a nagy szám, az OpenBSD csapat már évek óta ezt hangoztatja, hogy ha kapnak kapnak hardvert, akkor készítenek hozzá drivert... de ezt gondolom thuglife is meg tudja erősíteni.

Írhattam volna a szeretett DragonflyBSD-det is, valószínűleg. Szerintem ők sem utasítják vissza a driver fejlesztést, ha kapnak hardvert amihez meg kell csinálni...

Sőt! Ezennel bejelentem, hogy ha bárki donatál nekem 10 milliós vagy afeletti szervert (kis gagyi 2 forintos kínai cuccokkal nyilván nem foglalkozom ;), akkor a nem támogatott hardver elemeihez én is írok drivert. ;P

Nekem pl. nagyon jól mutatna az önéletrajzomban, ha a hívatalos kernel forrásnak csak egyetlen soráról is azt állíthatnám, hogy az az én munkám... Egy-két driver fejlesztésében való részvételre elég motiváció ez is. A gond csak az, hogy eddig még nem jutott időm, hogy olyan nagy témakörnek nekiessek, mint a linux driverek fejlesztése.

( kupcsik v | 2007. 01. 30., k – 18:03 )

En is remelem, hogy sok gyarto fog csatlakozni, es kiadja a specifikaciokat. Persze azok biztosan nem, akiknek van valami titkolnivalojuk. Mondjuk szabadalmaztatott cuccot hasznalnak anelkul, hogy ezt barki is tudna, vagy ilyesmi.

( Gabucino | 2007. 01. 30., k – 18:03 )

nagyon orvendetes hogy ujabb hangzatos szavak hangzanak el, vegulis a PR a legfontosabb, nade a hudestable linuxban X eve benn levo, API-following HFS+ driver mikor lesz olyan allapotban, hogy nem 5 masodperc alatt panikol el, hanem esetleg kicsivel kesobb?

(es ez csak a legszembeszokobb, a tobbire halisten nem emlekszek kapasbol)

persze ha tovabb akarom gondolni akkor esetleg azt is leirom hogy egy linux alatt mukodo HFS+ senkinek sem all erdekeben, mert akkor az osszes ext3/reiserfs fejle^H^H^H^H^Hganyolas a feledes jotekony homalyaba sullyedne...

szoval nehezen hiheto amit itt irnak, es ezert 0x00 az egesz equation erteke. vagy max 0x01.

--
the multiply techbanned hup user

Akkor itt az ideje, hogy az Apple is elárassza dokumentációval a linux kernel fejlesztőit. Hiszen ha a HFS+ az ő termékük, céljuk lehet vele, hogy minél több rendszeren terjedjen el. Így akár vevőket is szerezhet. (Pl. vevő látja, hogy jó a filerendszer, esetleg arra fog következtetni, h. a Mac OS is jó -> vesz egy Mac-et.) És nem kerülne nekik semmibe, nagy cégeknél amúgy is illik normálisan dokumentálni... :)

1. eloszor is tisztazd le magadban a kerdest, hogy akkor most ha csak stable code kerulhet a kernelbe mint ahogy a dogma hangzik, akkor miert van benne egy otvar bugware ami viszont a valosag, es ezekutan dontsd el hogy GKH segget csinal-e a szajabol

2. mifele doksi kell? opensource... (http://www.opensource.apple.com/darwinsource/10.3.3/xnu-517.3.15/bsd/hfs/)

--
the multiply techbanned hup user

Akkor max azért nem csinálja meg senki, mert senki nem használja... :)

A viccet félretéve biztosan van bugos driver a kernelben. És talán még bugreportolnak is a felhasználók. De lehet, hogy a fejlesztője azóta rég lelécelt, más meg nem veszi át a debuggolást. Talán szólni kéne nekik, h. ideje foglalkozni a bugos részekkel.

Azt meg nem tudtam, hogy ott a forráskód. Amúgy is forráskód!=dokumentáció, de esetünkben elfogadható.

láttál már windows 95, 98, 98SE, 2000, XP, vagy ME rendszereket? sokszor szívtam azzal, hogy ha nincs floppymeghajtó, akkor nem lehet normálisan feltelepíteni, mert folyton a floppyt akarja és lefagy, ha van, akkor meg minden fájl dialógusablak megnyitáskor 2 percig darálja a floppyt. Ehhez képest a linux csak akkor nyúl a floppyhoz, ha 1. létezik, 2. utasítod rá.
Persze, ha nem a piacvezető rendszer a nívó, akkor bocs.
Ez egy olyan hibája volt a windowsnak, amit sikerült úgy kb. 4-5 év alatt kijavítaniuk (de miért kellett ennyi idő egy cserélhető meghajtóegység állandó lekérdezésének a kikapcsolásához???? biztos ez is valamiféle ms szabadalom!)

de igaz, viszont csak akkor jott elo, hogyha egyszer az A: meghajtorol olvastal (kerestel ki a dialogusablakkal), majd leokeztad. A kovetkezo dialogusablak megnyitasnal ugyan onnan akarta folytatni a meghajto bongeszeset. Tehat ha az A: -ban nincs diszk es a dialogusablak az A: meghajtot akarja megnyitni mert legutobb azt bongeszte akkor jon elo ez a feature amirol a kollega beszelt. De sztem ez feature, nem bug.

Ez pl. drivertelepítésnél nagyon ciki volt, mert az alapértelmezett hely az A:\ ...
Meg a Sajátgép megnyitásánál... Meg minden panelen ahol szerepelt a floppy.

Persze a floppytlan gépet is ésszel kellett "megszerkeszteni", gubanc csak akkor volt a dologból, ha a Windowsnak a rosszul beállított/defaulton hagyott BIOS vagy az ilyen esetre nem felkészített (gány) floppy controller jelentette, hogy van bizony meghajtó, amikor nem volt. Na ilyenkor volt a két perces beállásos-várakozós móka.
Ha a BIOS-ban tiltottad a floppyt és a floppy controllert, akkor "önkompatibilitási okokból" megjelent egy "szellem" A: cserélhető lemez, így workaroundolta magát mindig egy sima "nincs lemez a meghajtóban" hibaüzenettel.

Tudott az xp olyat is, hogy rendszergazdakent matattal valamit a floppy-n, majd logout es huzas haza... aztan jon a telefon, hogy xy korlatozott jogu user semi cuccahoz nem fer hozza... mondtam: kizart dolog, semmi ilyesmihez nem nyultam azon a gepen. Tavolrol sajna nem volt elerheto, a jelszavamat termeszetesen nem adtam ki... kenytelen voltam visszamenni. Kiderult, hogy miutan a floppyt hasznaltam utoljara onnantol kezdve az xp osszes "megnyitas" ablaka onnan akart indulni (ne kerdezzetek miert) es xy-nak viszont nem volt joga onnan olvasni... megnyitottam egy allomanyt a dokumentumok mappabol, utana neki is Yoo lett minden.

Udv:
Feri

birom hogy vmi linuxos temaban vmi okos foss'er mindig felhozza a windowst, mert csak ahhoz ert
szanalom ez a portal bazmeg

foleg hogy X+2 eve nem volt a pc-mben floppy, ehhez kepest vigan installaltam mindenfele OS-t, including windows, szoval nem artana ha nem dolne ide a hulyeseg most...

--
the multiply techbanned hup user

>(es ez csak a legszembeszokobb, a tobbire halisten nem emlekszek kapasbol)

Igen én is ilyenekt írok, amikor konkrétan semmivel nem tudom alátamasztani amit mondok, de akarok valami ütőset írni a végére. :)

Ezzel az erővel írhattad volna az NTFS-t is, az is hasonlóan jó példa lenne.:)

( n0gabor | 2007. 01. 30., k – 18:16 )

hat nem tudom, de sztem ez nem biztos hogy ez hosszutavon a megfelelo megoldas (bar egyelore a linux tamogatottsaganak novelesere biztos hogy jo)

van egy Winfast 2000 RM tvtuner karim, ugyan nem open a specifikacioja, de a BTTV driver eleg kiforrott linuxon, mukodott is faszan egeszen a 2.6.16 kernelig, ott vmi API valtas tortent, ez azota nem megy a taviranyito (vmi hoax patch-el eletre tudtam kelteni, de nem messze nem volt 100%)

egyszeruen nem forditodhat eleg figyelem minden egyes HW-ra, meg azok masodlagos funkcioira, igy tuti nem lesz minden olyan minosegu, mintha az adott hardware vendor tartana karban (akinek anyagi erdeke hogy 100% legyen a driver meg minden), foleg igaz ez a nem annyira common hardware-okra

masik oldalrol egyre tobbet lehet hallani hogy egyre tobb uj feature kerul a linuba, es hatvanyozottan no a bugok szama, sajnos mostanaban enis belefutottam parba...mi lesz akkor ha a fejlesztok nekiallnak inkabb az uj driverek megirasanak, meg kevesebb energia forditodik a bugmentesitesre

::powered by Archlinux

Valójában jól gondolkodsz... Igazából melyik cég merné bevállalni, hogy a hardverjét odaadja a Linux Közösségnek, hogy fejlesszenek rá drivert? A jelenlegi kódminőség alapján csak rossz, bugos meghajtó program keletkezne hozzá, amelyik csupán presztízsveszteséget okozna a cégnek. Szóval nem éri meg. ;D

Már tegnap is akartam írni, hogy a sokat emlegetett nvidia driver pl. win alatt is szánalmas, ha elégedett vagy vele, akkor valószínűleg win-en se játszol túl sokat. :) Tele vannak gányolással a különböző programokhoz. Van amikor az újjal nem megy ami addig ment, stb. Igazándiból korántsem annyival jobbak a win-es driverek, mint lehetnének. Max. egy pár kbyte-os modul helyett felraknak még 100MB szemetet.

en mar itt csak szettarom a kezem, hogy a hupper foss scene ugy nez ki jobban vagja a windows oda-vissza-keresztbehakkolasat, mint en... (bar az nLite nevu veryadvanced tool ismeretevel ugynezki mindezidaig egyedul vagyok)

sot.

a linuxforumrol ma megtudtam hogy a thief2-t hogy lehet wine-al elinditani.

a hupon megtudtam hogy a livemessengerben van sharedfiles.

zsir.

--
the multiply techbanned hup user

Sztem a bugvadászat, meg egy "új" hardver driverének kifejlesztése nem ugyanaz.

Nem elképezlhető, hogy vkinek nincs kedve mások driverének kódjában turkálni hibákat keresve/javítva, míg mondjuk szívesen írna usb-re köthető vibropengés mákdarálóhoz doksi alapján szinte egyből működő drivert?

Az ilyenekhez én kicsi vagyok, de a bele mernék vágni ilyesmibe, akkor tutira a második verzióval foglalkoznék.

Egyébként ez a cégeknek is jó kellene, hogy legyen, mert ezzel kvázi outsource-olnak egy csomó melót, kirúghatnak fejlesztőket, csökkenthetik a költségeiket, stb. Ha meg valami kvázi jogi alapra is helyezik a dolgot, akár minőségellenőrizhetnék is a kész drivert, legalábbis a nagy kereskedelmi disztrók kiadásaiban, vagy vmi ilyesmi. Szóval nem feltétlenül jelentene ez bármiféle anyagi v. presztízs veszteséget a hw gyártóknak.

és a kirúgott fejlesztőknek annyi szabadidejük lesz, hogy nekiállnak otthon munkanélküliként linux drivereket fejlesztgetni a volt munkaadójuk megrendelésére a linux közösségen keresztül ;-)
Kár, hogy nincs egy nagy gyáram sok fejlesztővel, mert egy részüket már raknám is lapátra, minek fizessek nekik, ha ingyen is kapok munkaerőt? ;-)

Nem lesz ez így jó!

Ez nem "jóság" kérdése. A nagyvállalatok legszívesebben így működnek: csökkenő kiadások mellett növekvő bevételeket akarnak látni. Tehát ilyen szempontból nekik ez rettentően megérné.

Persze az a bökkenő, hogy eddig sem szakadtak bele a linuxos driverek fejlesztésébe, szóval nem kerül cégenként lapátra 20-25 ember, aki eddig csak a linuxos driverek karbantartásával foglalkozott 7x24 órában, tehát ettől az ötlettől nem csökkennek a költségeik érdemlegesen.

Viszont az is igaz, hogy a doksit sztem nyugodtan ki lehetne adni vmi minimális supporttal (egy kapcsolattartó mérnök mail címét értve alatta) és nekik így nulla további befektetés mellett lesz egy több OS alatt is elég jól támogatott hardverük. Az meg mégiscsak bővülő piacot jelent valahol.

( wolphie | 2007. 01. 30., k – 19:50 )

"komplett és működő meghajtóprogramot kap az eszközéhez"

Ezek szerint a csodaenterspajzkernel csodalatos atalakulasanak lehetunk majd szemtanui? :)

( turul16 v | 2007. 01. 30., k – 20:17 )

1. 2.6 kernel kiválló driver modellel rendelkezik.
2. Egy-egy hasomló eszköz drivere használhatja ugyanaokat a függvényeket, ezek helyeségét többszörösen is ellenőrzik
3. Minden eszköz kategóriában van támogatott eszköz, tehát 2008 -as linux desktop évében ez óriási előnyt jelenthet.
4. Terjednek a mobil eszközök, akik ebbe való chippet gyártanak azoknak előny, ha már van mainline kernelbe kód az ő eszközéhez.
5. Ha cégek visszaútasítják ... nem mondhatják, hogy közösség szándékosan kihagyta őket a bulibol :)
6. Többen említették, hogy biz. hardverek driverét nem tartja karban senki, talán ez azért lehet, mert a driver írója már nem használja az észközt nehagy isten eladta, vagy elromlott így nem tud mit kezdeni a bug reportal, cég küld eszközt a doksi mellé és lehet ellenőrizni. Ne hogy fejlesztőknek kelljen azért fizetni, hogy cég eszközét Linuxos arcok is megvegyék. Az igéret ellenőrése is egyszerű, csak lőj fel egy kernelt tedd bele az eszközöd...
7. Az kvázi az egész FOSS közöség közösen is tehetne ilyen ajanlatott, tehát *BSD,Linux... stb. akiknek van elég emberük egy ilyen igéretet betartani, lehet hogy úgy ütősebb.
8. Legroszabb ami történhet, hogy az igéret után nem történik semmi a cégek részéröl :)
Csak ennyit akartam vár a söröm, bye...
------
gentóhuszár

1. ????

ezt most hogyan kell érteni. ? Az a kiváló modell, hogy a kernelforrásfa fejlesztése során ex-has átnevezgetnek egy rahedli függvéynt, és a tőle függő összes cuccost mind át kell hegeszteni ? Mindjárt gondolok konkrét példaként a lirc modulokra, amit mind át kellett hegeszteni, mert valami nagyeszű kitalálta, hogy a BTTV_AVERMEDIA az pl. nagyonnemjó, BTTV_BOARD_AVERMEDIA kell helyette. Meg vannak hasonló jó kis átnevezgetések a drivers/net szekcióban is. nagyon élvezetes... :(

És ez nem 2.4-ről 2.6ra jött elő, hanem 2.6.1x valemennyitől. rosseb emléxik már ilyen részletesen.

---------

Nem a zsömle kicsi, a pofátok nagy...

sajnos az ilyen közösségileg gányolt szoftverekben előfordul ez. Pl. a gcc forráskódja folyamatosan ilyeneken esik át.
Ennek az egésznek az lehet az oka, hogy régen tényleg csak ad-hoc adtak neveket függvényeknek, makróknak, stb és nem volt egy központi névkiosztás, illetve névhasználati felügyelet. Amikor ezen nevek használatát egységesítik és szabályokat alakítanak ki rá, akkor sajnos nem nagyon van más megoldás: vagy foldozgatnak még mindenféle #define-okkal, hogy a régi név is életben legyen, vagy fogják és kihajítják a régi neveket úgy ahogy vannak és csak az újakat használják.
A dologban a jó az, hogy innen kezdve viszont az új kódokat már tisztán és egységesen lehet fejleszteni és egyszer csak letisztul minden. Remélem (valaki nézzen bele egy 2.95.3-as gcc-be és egy 4.1.1-esbe és érezni fogja a különbséget!)

Én is szeretném már, ha vége lenne ezen nagy projektekben az állandó átmeneti állapotnak...

az akkor fog megtortenni, amikor a linux esetleg hasonloan tamogatott lesz mint az osx vagy akar win, de addigra az osszes hekker fujjozni fogja, es egy mas tak projectet fog epiteni,es hasznalni tudomisen haiku os.

ha valami nagyon kiforrott, nagyon szép, nagyon jo, minden megy, az nem kell a hekkernek:D

::powered by Archlinux

Node az atnevezesnek/egysegesitesnek eppen az lenne a lenyege, hogy ha mar kitalaltuk a fuggvenynevet, akkor MINDENHOL azt hasznaljuk. Hogy pl. egy egyszeru multifile search-el megtalaljuk az elofordulasait.

Ertem en, hogy a fast&dirty megoldas a #define, typedef meg minden, csak azzal generaljak a problemat, nem pedig megoldjak. A letisztulasi folyamat meg eleg ritkan jellemzo egy szoftverfejlesztesre (bar lehet, hogy rossz fejlesztesekben vettem reszt). Ha valami gany, akkor az tobbnyire az is marad, legfeljebb csak olyan helyeken okoz problemat, ahol ritkabban tunik fel. Jo pelda az Uj Linux Kernelfejlesztesi Model. Lehet, hogy a mag tisztabb-szarazabb-biztonsagosabb lett, viszont cserebe atlapatoltak a szart a driverekbe. Eleg sokan szembesulnek azzal, hogy kernelfrissites soran megszunt a tamogatas a mindenfele hardverukhoz :).

van komplett development cd is linux kernel driverek és modulok fejlesztéséhez. Azon rajta van egy halom doksi és egy 2.6.16-os kernel forrás. Az általad említett alapmű annyira ki van emelve, hogy közvetlenül a gyökér alatt kapott egy DDK3 nevű könyvtárat.

http://www.kernel.org/pub/linux/kernel/people/gregkh/ddk/

( zoli78 | 2007. 01. 31., sze – 00:28 )

Szerintem egy ilyen szolgáltatás, ha elég jó minőségű és van arra garancia, hogy ezek a dolgok tartva is lesznek (a kernelfejlesztők közössége csak garancia rá), akkor még akár fizetősen is érdekelheti a cégeket. Bár az is lehet, hogy amelyik cég hajlandó volt erre áldozni, vagy egyeltalán érdekli az, hogy támogatva legyen linux alatt, már megoldotta valahogy magának.

a kernelfejlesztők közössége csak garancia rá

hat persze. ja, ki is volt a multkor aki mar commitolta is a git treejebe hogy ne lehessen tobbe proprietary modulokat betolteni, hogy vegul linusnak kelljen elpicsaznia a hibas gpl ertelmezes miatt? gkh.

es ki is ir most a gyartokhoz szivelyes blogentryket? gkh.

csak epp lefelejtette a vegerol, hogy "ja bocs az irt driver termeszetesen gpl lesz es copyright by gkh LOL OWNED LOL"

mifele garanciarol van szo egeszen pontosan ezesetben?

--
the multiply techbanned hup user

( Vales | 2007. 01. 31., sze – 09:37 )

Dícséretre méltó kezdeményezés!
Ahogy Robin Hood mondta: "A nemesség nem születés joga, hanem a tettekben ismertetik fel." :)
Remélem a MikiSzoft nem fogja a körmét aggatni (ez pedig félő, hogy igen).
A WiFi kártyákra (is) nagyon ráférne egy ilyen kezdeményezés.

Milyen kár hogy
1) Robin Hood nem élt (nagy valószínűség szerint)
2) Akikről mintázták azok gátlástalan rablók és gyilkosok voltak, nem ám 'gets from the rich, gives to the poor' (Dennis Moore, Dennis Moore...)

Az esetleges párhuzamot a cikk topicjával mindenki rakja össze maga.