Linux-2.6.33-libre - blobmentes kerneldisztribúció az FSFLA

Kernel

A Free Software Foundation Latin America bejelentette a Linux-2.6.33-libre kerneldisztribúcióját.

"A Linux nem szabad szoftver 1996 óta, amióta Torvalds úr elfogadta az általa 1991 óta terjesztett Linux [kernel]disztribúciójába az első nem szabad szoftver összetevőket. Az elmúlt évek alatt, miközben a kernel 14-szeresére nőtt, az eszközmeghajtó-programokhoz szükséges nem szabad firmware-ek mennyisége riasztóan, 83-szorosára nőtt. Nekünk, szabad szoftver felhasználóknak egyesítenünk kell erőinek, hogy változtassunk ezen a trenden, és a megoldás része a Linux-libre lehet, [...] Mi nem tartjuk karban a Linux-libre forrásfájljait közvetlenül. Helyette a "deblobbing" (blob eltávolító - a szerk.) script-eket tartunk karban, amelyek megtisztítják a Linux "forrásokat", így állítva elő a Linux-libre forrásokat."

A bejelentés elolvasható teljes terjedelemben itt. A források itt.

( gUHU | 2010. 03. 02., k – 08:48 )

Néha az az érzésem, hogy ez a baromi nagy szabadságvágy az ami akadályozza őket. Eszembe jut az egyik kedvenc bölcsességem. A szabadság ott ér véget, amikor a szabadságom által határt szabok mások szabadságának.

Hisznek benne. Ráérnek. Csinálják.

-- "Bízzál Istenben és tartsd szárazon a puskaport!" - Cromwell --
-- Sayusi Ando - http://sayusi.hu --

mondjuk arra, hogy pereljünk.minden.baromságért világunkban gyárthass/forgalmazhass olyan computereket, amely után nem perelnek be azzal, hogy sérted valaki szellemi tulajdonát. de a szellemi szabadalmak óta ez a blobmentes kernel sem garancia semmire. egy startup céget jó eséllyel porondon kívülre lehet vágni akár egy per lebegtetésével is. a TomTom vfat szabadalom miatt lett beperelve úgy, hogy egy darab blob sincs a linux kernel vfat kódjában.

En nem hinnem. Ui az ilyen egyesek szerint "szelsoseges" megatartasnak koszonheto, hogy nehany - aztan evek mulva mar normalis nyilt forrasu - cucc letrejon egyaltalan. Az teny, hogy adott idopontban az emberek nagy reszenek ez a magatartas furanak/szuksegtelennek tunik, azonban hosszu tavon hozhat megoldasokat. Nezzuk csak azt a peldat, hogy nem nagyon szeretik, hogy zart forrasu kernel modul, meg ugye "stable module API non-sense" es hasonlo filozofiak: ha ez nem lenne, es elfogadnanak mindent, lenne akar ABI szinten evekig stable modul interface a hw gyartoknak stb, imho kevesebb driver jelenne meg nyilt forrassal, es egy ido mulva az egesz kernel kvazi madjnem binary blob-okbol allna csak, egy ido utan mar a kernel fejlesztes is szinte lehetetlen lenne, mert ezekhez kene alkalmazkodni, stb.

Pont az ilyen szelsoseges ideologiak miatt olyan a Linux a mai napig amilyen. Szoftverfejlesztesbe nem jo ideologiat keverni, mint ahogy az sem jo, ha ossze-vissza megy a kapkodas.

Lehet hosszu evekre elore fejleszteni, mindossze az kell hozza, hogy legyen roadmap, es ne attol fuggjon a fejlesztes menete, hogy Linusnak hany fokos volt a reggeli kaveja.

Lehet uj dolgokat implementalni a kernelbe ugy, hogy megtartjak a korabbi reteggel valo kompatibilitast, vagy wrappert implementalnak ami athidalja a ketto kozti kulonbseget. Jobb helyeken ezt hivjak rendszertervezesnek.

Ugyanigy, egy normalis fejlesztesnel megkulonboztethetoek a fejlesztesi, tesztelesi, es publikus agak, es a publikus agban nem folyik hitvita. Lasd: az utemezok koruli faszolas.

Egy kulso ceg eseteben akkor nyero egy operacios rendszer, ha az APIja egyseges, atlathato es az eszkozkezeles fejlesztese konnyen implementalhato. Aki mar latta sysfs-t kozelrol, az tudja, hogy ez nem az. Lehetne meg polemizalni a modul templatek hianyarol is.

--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

a Linux szóhoz ma általában sikertörténetek kacsolódnak. nem csak desktopból áll a világ. a Google szervereinek valószínűleg egyetlen olyan blobra sincs szüksége, amit ez a kernelváltozat kivág.
egyébként a linux desktop sem azoknak készül elsődlegesen, akik nem akarnak fizetni az operációs rendszerért. talán ezért okoz egyeseknek csalódást.

A linuxos sikertörténetet kicsit árnyalja, hogy jelen pillanatban a Linux legnagyobb vonzerejét az ingyenesség és a nyitottság adja. Megfigyelhető, hogy pont azok a "sikeres felhasználók" akik tömegegesen használják. Egy Google vagy Facebook esetében még masszív, tömeges, liszenszelés esetén is olyan összegek jönnének ki egy kereskedelmi OS-re, amivel már simán fenn lehet tartani egy házi fejlesztő csapatot, aki testreszabja a rendszert. Ezeknek a szolgáltatóknak egy blob megléte, vagy meg nem léte, nem oszt, nem szoroz, mivel:
a, rendelkezik akkora súllyal, hogy "blob mentes" vasat vegyen
b, megoldja saját erőforrásból az adott vas támogatását

Ha a beágyazott piacot nézzük, hasonlót lehet látni. Egy telefon esetében fillérekre menő harc megy a darabár leszorítására, és egy OS, egy okostelefonnál a vas súlyával vetekszik.
Egy célhardvernél a driver implementálás nem igényel blob-ot, itt megincsak az OS ára és implementálásának az ideje ami döntő.

A firmware blobok megint egy érdekes kérdéskkört vetnek fel. Ezen blobok elsődleges célja a flash nélküli eszközök implementálása, és ezáltal javítani az eszköz eladhatóságát (darabár csökkentése, fejlesztési/hibajavítási lehetőség). Ezek esetében nem várható el, hogy a gyártó megnyissa a forráskódját, mert akkor 3 héten belül lehúzhatná a rolót. Ezt a open-source komcsik nem tudják agyilag felfogni, és ezen blob-ok kernelből való kitiltása automatikusan az adott eszköz gyártó általi támogatásának a megszűnéséhez vezetnek.

--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

( Hiena v | 2010. 03. 02., k – 09:01 )

Latom, Che szelleme meg izzon langol azon a videken...
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

( uid_1526 | 2010. 03. 02., k – 09:23 )

Az nem hír, hogy kiirtják a blobokat (

rm *blob*

-ot minden 5 éves Pistike tud futtatni), az lenne hír, ha adnának funkcionalitásban hasonló alternatívákat is. Mert ugye addig ennek nem sok értelme van.

( turul16 v | 2010. 03. 02., k – 09:52 )

Ekkora hulyeseget.

Lenyen tobb firmware a kernelben, utalom levadaszni oket, legalabb egy gyujto oldal jo lenne, de neha a gonosz vendor meg szabadon masolgatni sem engedi.

Erdekes lenne kernelt forgatni, ha minden firmware nyilt lenne , kene meg par giga tool egy forditashoz.

Legtobb firmware letezeserol azert tud a nep, mert a gyarto kisporolt egy romot, egyebkent fel sem tunne.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

( the_nameless89 | 2010. 03. 02., k – 10:15 )

Kezdem unni ezt az erőltetett "jaj legyen minden szabadszoftver - zártkódfujfuj" felfogást. Azt várják, hogy majd minden fejlesztő hanyatt-homlok ugrani fog, hogy nyílt modulokat írjon? Sokszor még a tulajdonos cég sem tud rendes firmware-t írni az adott eszközhöz, pedig ismerik a cucc specifikációját. Egy zárt hardver esetében, amiről senkinek semmi tudomása nincs, csak az hogy létezik, elég nehéz nyílt meghajtót írni. Ha az adott hardverről van nyílt és részletes specifikáció, az más. Viszont a jelenlegi helyzetben a "csak nyílt forrás, vagy semmi" nézet nem működik.

SKL - leírásgyűjtemény és informatikai portál

Sokszor még a tulajdonos cég sem tud rendes firmware-t írni az adott eszközhöz, pedig ismerik a cucc specifikációját.

Látod, ezért kell nyílttá tenni a forrást, hogy valaki kijavítsa a hibákat és a gyártó cég eltűnése után 2 évvel is karban tudja tartani....

---
Repeat after me: I Will Use Google Before Asking Stupid Questions...

Ööö.. ezekről a firmware blob-okról többségükben azért tudunk egyáltalán, mert a gyártó kispórolja a rom-ot
a cuccról, és inkább a driver tölti fel rá az eszköz inicializálásakor.
Ergo nem nagyon van mit karbantartani rajta, ha a gyártó cég meg is szűnik/behintik a helyét sóval, akkor
is működni fog a legutolsó kiadott fw a legutolsó kiadott hw-ukkel.

A driverek azok más kérdéskörbe tartoznak, de nem is ezekről volt szó.

Pontosabban csak működne, ha az űberkreatív kernelfejlesztők nem változatnának az APIn amin keresztül töltődik a firmware. Pl. 2.4-ről 2.6-ra váltásnál kukázhattam ki egy softmodemet, mert a gyártó már nem supportálta a terméket, az új kernel meg nem támogatta a firmware töltő ioctl hivásokat.
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

Kernel API probléma.
Mivel a 2.4 és 2.6 között a sysfs miatt elavult lett egy csomo ioctl hívás. Ha a designnál nem érvényesült volna a történelmi amnézia, és minden szar ami a 2.4-ben van mentalitás, akkor talán megoldható lett volna, hogy még 4-5 évet menjen ugyanaz a vas.
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

jee. szoval akkor a _driver_ is closed volt, hogy nem lehetett az uj apira modositani?
vagy csak nem erte volna meg pocsolni vele? amugy okké :) csak nem ez a $topic
amugy sok helyen ezert van meg mindig 2.4, nyilvan nem jokedvukbol, de az ami egyszer mukodik, azt ne
baszogassuk mentalitas neha celravezetobb.

Gyarto altal mellekelt driver volt, egy onkicsomagolo es fordito shell-script formajaban. A firmware (rockwell modem emulacio) binarisban. A gond az volt vele, hogy mezei userkent nem ereztem feladatomnak, hogy egy 5k HUF-os kartyara, ugyanennyi erteku mernokorat forditsak, hogy a /temp turasaval kimasoljam a forrast, es utana kitalaljam, hol szorit a cipo.
Ami leginkabb bosszant az ilyenben, hogy ebben a formaban szopatas szagot erzek. Ok, a Linux ingyenes, tehat nem varok el supportot es tarsait, de rohadt perverznek erzem azt, amikor egy verziovaltassal beleteszik a locsot az ember szajaba.
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

Talán nem tűnik ki az írásomból, de én ezzel teljesen egyet értek. A logika azt diktálná, hogy a hardver legyen nyílt, hogy még hatékonyabban lehessen használni. Számtalan olyan fórumtémát látni, amiben a felhasználók a UNIX/Linuxhoz vesznek hardvert és nem fordítva. Azon gyártók termékei, amikhez nincs normális nyílt eszközmeghajtó, hátrányban szenvednek. Nemcsak a hatalmas méreteket öltő Linux felhasználótábor miatt, hanem mert a nyílt hardverekből jobban ki lehet sajtolni a maximális teljesítményt, a pontos specifikáció és a nagyobb fejlesztői közösség közreműködésével. Egy hatékonyabban használható terméket pedig jobban vesznek a vásárlók. Vegyük példának a legszembetűnőbb fejlődést a videokártyák terén. Az más kérdés, hogy egyes disztribútorok nem tudják rendesen beépíteni a rendszerbe. A fentiek szerintem logikusak és sokan tisztában vannak ezekkel...

Akkor miért is van ez a nagy elzárkózottság? Azért, mert akkor nyilvánosságra kerülnének a termékek gyenge pontjai. Egy wifimodul gyártónak például semmi más oka nem lenne a specifikáció elzárására csak az, hogy az általuk gyártott termék nem a legtökéletesebb. Ez nagyon sok zárt forráskódú szoftverre is igaz. Mindenki emlékszik a Microsoft GPL-t sértő programjára. Amikor rájöttek, hogy ezt bizony nyílttá kell tenni, egy rakás időt kellett várni, mire meg merték mutatni a kódot.

SKL - leírásgyűjtemény és informatikai portál

Azért, mert akkor nyilvánosságra kerülnének a termékek gyenge pontjai. Egy wifimodul gyártónak például semmi más oka nem lenne a specifikáció elzárására csak az, hogy az általuk gyártott termék nem a legtökéletesebb.

Hú na ez azért rohadtul nem így van! Nem mondom, hogy nincs arra példa, amit írsz, de messze nem ez a fő szempont.

Konkrétan egy wifi adapter _nem is kaphat_ rádiósugárzási típusengedélyt, ha a felhasználó bármilyen módon képes lehet módosítani azt úgy, hogy pl a tunert el tudja hangolni az engedélyezett tartományon kívüli frekvenciára. Elég durván ellenállónak kell lennie egy alaposan hozzáértő ember módosítási kisérleteivel szemben is. Nyílt, módosítható firmware-rel elképzelhetetlen, hogy az FCC engedélyt ad rá.

Aztán itt van a videokártyák kérdése. Vasat sok artimetikai végrehajtóegységgel tud gyártani akárki. 1-2 milliárd forinttal a zsebemben (ami valljuk be, ebben az iparágban nem nagy pénz) kimennék Tajvanra, legalább 3-4 céget találnék, ami megcsinálja nekem. Csak éppen ebből még önmagában nem lesz jó teljesítményű 3D gyorsító. Gyakorlatilag ma már minden a driverben lévő shader fordítón és végrehajtás ütemezőn áll vagy bukik. Ha kinyitnák a forráskódját, akkor a konkurens kártyája is használhatná ugyanazt. Sőt megjelenne a piacon még egy rakás szereplő, aki árban lazán alávágna a mostaniaknak. Neked, mint vevőnek nyilván ez jól hangzik, csak ha utána nem éri meg a fejlesztési effortot belerakni, mert rögtön lelopja a konkurencia, akkor hosszabb távon nem sok fejlődés lesz ezen a téren.

Nézd csak meg, hogy mit tudnak a Gallium3D meg hasonló megoldások a gyártó zárt forrású driveréhez képest. "Persze mert még nincs optimalizálva" szokott erre jönni a válasz, hát ez a "nincs optimalizálva" dolog nem ritkán 10:1 arányú teljesítménykülönbséget jelent. Megvennél egy kártyát, ami 100eF áron annyit tud, mint egy 10eFt-os kártya? Megvennél egy kártyát, ami 200W-ot fogyaszt és annyit tud, mint egy 20W fogyasztású kártya? Ma egy 3D kártya _maga a driver optimalizáció_. Eszük ágában nem lesz kinyitni a forráskódot. Legfeljebb idővel a szabad szoftveres fejlesztők jobban kikupálódnak a shader cuccok optimalizálásából és akkor csökkeni fog a különbség a nyílt és zárt megoldások között. De ehhez egy nagy adag alapkutatási eredmény is kell.
---
Internet Memetikai Tanszék

( skylooker | 2010. 03. 02., k – 15:09 )

Mint "opensource komcsi" úgy látom, hogy a kódok közt elég sok takargatni, szégyelni való van. Továbbá vkik kitalálták, hogy milyen jól lehet szoftverrel kaszálni, elkezdtek "magas szinten szolgáltatni", létrehoztak egy iparágat, aminek ilyen mértékben kérdéses a létjogosultsága is. Mivel be szabad csapni azt, akit lehet, ez így is fog maradni jódarabig.

Ilyen esetben azért érdemes elgondolkodni pár dolgon:

a, A cégek pénzt fektetnek az eszközök és a hozzá tartozó driverek kifejlesztésébe. Ezt az összeget vissza is akarják kapni. Emiatt ezeket a költségeket beépítik a termékeikbe, adott esetbe úgy is, hogy a nagyfogyasztóknak szánt termékeikhez csak egy bizonyos architektúrához tartozó drivereket adnak, és más architektúrákra az eszközt felárral szállítják. Akár mennyire is ágálnak egyesek ellene, ez fair megoldás, mert a vevő nem kötelezheti a gyártót, hogy azért kedvezzen neki, csak mert kék a szeme.

b, Az adott technológia piacon történő megjelenése időkritikus, amennyiben valaki, valamit megkódolt azt könnyebb lemásolni, mint nulláról megírni. Ugyanígy, egy adott fejlesztésbe a időben történő piacra jutás miatt kénytelenek quick&dirty megoldásokat alkalmazni. Ezzel mindenki tisztában van aki kódolt már fizetős projectet szűk határidőre. Ronda, de működik, nincs kérdés.

c, A b, pontban leírt "kódátvétel" mellé bejönnek a szabadalmi és reverse-engineering kérdések is. Egyrészt, minden fejlesztő cég árgus szemmel figyeli a többit és lesi, hogy mit tudnának implementálni a másiktól, másrészt folyamatosan dolgoznak azon, hogy minnél jobban szopathassák a konkurenciát. A szabadalmi hivatal és szerzői jogvédő jellegű dögkeselyűk tovább rontják a helyzetet, különösen ha mondjuk az adott cég egy szabadalmat fizet és kettőt implementál alapon fejlesztett.

--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

nem a driverböl lesz pénze, hanem a termékből. aminek a belső működése - ideértve a mikrokódot, firmware-t is - elképzelhető, hogy olyan megoldásokat tartalmaz, amit nem szívesen látnának viszont a konkurenciánál - nekik pénzben mérhető veszteséget okozva.
ez egyrészt.
másrészt meg, ha még akarnák is, ők is licenzelhetnek technológiát egy másik cégtől, és a szerződésben valószínűleg csak a kód saját termékeikben való használatára kaptak jogot, annak megnyitására, és terjesztésére viszont nem.

Hardverből él meg a gyártó és ennek a része a firmware és a driver is. Egy hardver működéséhez hozzátartoznak ezek is. Ezeknek a visszafejthetetlensége a cégnek ad időelőnyt a többivel szemben. Az imgyenletölthetőség egy plusz szolgáltatás, hogy az adott gyártó termékeit minnél könnyebben használhassa a felhasználó.
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "