Vlákno názorů k článku Dell zjednoduší správu ovladačů v Linuxu od glx - Neda mne to, abych tady (jako jinak spokojeny...
-
glx (neregistrovaný)Neda mne to, abych tady (jako jinak spokojeny dlouholety uzivatel Linuxu) nenapsal jednu vec:
Vsechny tyto komplikace s ovladaci by odpadly pokud by ABI v jadre neovlivnovaly myslenky nekterych fanatiku. Nutnost prekladat znovu (a nekdy i trochu modifikovat) ovladac pro temer kazdou verzi jadra je tou nejvetsi slabinou Linuxu. Az se toho zbavime (a neni to technicky nybrz ciste "politicky" problem), bude to velky svatek.
Da se chapat nekompatibilita binarky ovladace mezi "velkymi verzemi" jadra - 2.2, 2.4, 2.6, ..... to se pochopit da. Ovsem nekompatibilita mezi treba dejme tomu 2.6.18 a 2.6.21, to pusobi spise jako vyplod nejakeho sabotera. -
glx (neregistrovaný)Ty zmeny tam delaji z jakychsi pofidernich duvodu, ktere souviseji s pocitem, ze by se snad zastavil vyvoj jadra, pokud se subverze od subverze nebude menit jako chameleon. A pak tam jiste hraje roli i GNU fanatismus - umyslne znesnadnovani tvorby binarnich uzavrenych ovladacu (jenze tim otravi i vyrobce, kteri by jinak byli i ochotni delat ovladace otevrene).
-
Martin Bajer (neregistrovaný)GNU fanatismus - To zní jakoby byli někteří jaderní vývojáři uchyláci. Co si pod tím představuješ?
Nepleť si příčinu a následek. Problém dělají binární ovladače. Ne ti co se jim brání.
Určitě víš, že je kernel šířen pod GNU GPL v.2. To znamená, že všichni kteří se na něm podílejí s touto licencí dobrovolně souhlasí, a také jelikož to jsou inteligentní lidé lze předpokládat, že ví co dělají. Tvorba binárních uzavřených ovladačů je v příkrém rozporu s filozofií GNU GPL resp. svobodného softwaru. Každý kdo je alespoň trochu při smyslech netouží po uzavřených ovladačích. Z druhé strany vzato tvorba binárních ovladačů nepřinese svobodné ovladače. Je to buď a nebo. Vzpomínám si na jednu výstižnou odpověď Davida Kolera, když se ho kdosi ptal proč dělá jen velké koncerty: "Protože když chceš dělat velké, tak nemůžeš dělat malé". -
LO (neregistrovaný)Samozřejmě snadno dostupné ovladače instalovatelné bez kompilace jsou v zájmu každého uživatele Linuxu. Zachování duševního vlastnictví k HW (tedy utajení zdrojáku ovladače) je zase v zájmu každého výrobce HW, a navíc v některých případech nutnost před zákonem (například driver nesmí povolit překročení některých parametrů u WiFi a modemů, což u open source driveru nelze zaručit). No a v zájmu vývojářů Linuxu zase je, aby měli open source ovladače pro veškerý HW, protože open source je prý dobrý. Když jsou ty zájmy takhle různé, těžko si to sedne :)
-
Dodržování limitů výkonu vysílače je záležitost provozovatele zařízení, ne tvůrce ovladače. Není žádný objektivní důvod proč uměle bránit nastavení tak velkého výkonu, že s pomocí WiFi karty bude možné ohřát si objed jako v mikrovlnce, pokud to zařízení fyzicky umožňuje. Důležité je jen to, že se takový výkon nenastaví samovolně. -
LO (neregistrovaný)Minimálně v případě modemu tento neprojde homologací, pokud může vybočit z parametrů způsobem, který by mohl poškodit telefonní síť. To je důvod, proč řada winmodemů nemá open source drivery. U WiFi karet je to nejspíš podobné - například na některých frekvencích nesmí být schopny vysílat atd.
-
LO (neregistrovaný)Ta homologace se týká výrobku jako celku, včetně firmwaru (ukažte mi modem bez procesoru s rychlostí nad 2400 bps). Winmodem ani velké procento WiFi karet (a mimochodem třeba řada zvukových karet) si bez uploadu firmwaru do zařízení ani neškrtne, a nefunkční "cihla" asi homologaci nedostane. A protože firmware zařízení je součástí driveru (který provede ten upload firmware do zařízení), nelze dost dobře mít open source driver, protože by umožnil parametry zařízení výrazně změnit.
-
Ukažte mi modem, který nepodporuje několik vzájemně napěťově nekompatibilních typů linek na stejném rozhraní, ale zároveň hardwarově umožňuje softwarovou regulaci napětí mimo bezpečné hodnoty.
O WiFi kartách teď plácáte nesmysly. Až do nedávna u nás bylo pásmo 5GHz licencované a nebylo možné ho používat pro soukromé sítě bez povolení od ČTÚ. Podle vaší logiky by tedy žádné zařízení podporující standard IEEE802.11a (5GHz WiFi) nemohlo projít homologací, respektive by měly být prodejné pouze proti povolení od ČTÚ na využití pásma 5GHz k provozu WiFi sítě. Přesto mám v tuto chvíli na stole hned 2 zařízení, která jsou homologovaná, podporují IEEE802.11a, koupil jsem je ještě před uvolněním pásma 5GHz pro nelicencované soukromé sítě a žádné povolení jsem nepotřeboval. -
Hardware se deli na dva druhy: komplikovane zalezitosti, ktere vyzaduji komplikovane chipy na zarizeni (napr. graficke karty) - v takovem pripade ovsem je know-how v onech chipech a nikoliv v ovladacich (viz i nedavne prohlaseni AMD/ATI), a triviality jako jsou winmodemy, kde jednoduse neni zadne dusevni vlastnictvi ktere by stalo za to chranit, pokud tedy nepatrite k lidem kteri uznavaji napr. patent na doubleclick.
-
anonymníOS GNU/Linux nepotrebuje spravu ovladacu, ani zadne podobne nesmysly.
Bezny uzivatel nevyzaduje kvalitni ovladace, bezny uzivatel vyzaduje aby mohl spoustet vsechny programy, ktere sezene a to nejlepe bez konfigurace cehokoli a na jedno kliknuti.
Soucasny zpusob (kompilace kernelu) je plne vyhovujici a lameri z Dellu na tom pracovat mohou, presto se to uzivatelu jako jsem ja nastesti netyka, zadny ze skutecnych GNU/Linux developeru spravu ovladacu nepotrebuje, mame find, grep a kernel/Documentation/.
Programovat OpenSource pro nekoho jineho, nez pro programatory je zvrhlost, BFU se spokoji s widlemi a jejich klony ala *buntu $hit/Debilian. -
anonymníJa bych proti Debianu a jeho derivatech nerekl jedine krive slovo, kdyz by z nej markentingovi trotlici denne nedelali the best of the world. Vzdyt je to tu vsude samy Debilian / *buntu $shit / Suse / Mandriva / DesktopBSD / GreenLinux a same podobne distribuce pro lamy, o kterych bohuzel pise take jedna z lam, z toho jsem znechucen a tak trolluji v diskusich a snazim se zpet vnest rovnovahu.
Debian je uplne obycejna distribuce, neni v nicem nadprumerna, nikam se nehodi vice, nez konkureti a jedina vyhoda je, ze byl tvoren pro Debbie (pro zenskou), tzn. neni logicky a vetsina jeho (napriklad) cest ke konfiguracnim souborum nedava smysl, tzn. nelze si je odvodit, jen se je naucit z pameti, coz je memory-wasting...
Za svinsky marketing by se melo strilet, Vista $hit, *buntu $hit, Solaris $hit.
Nelze pouzivat google, aniz bych narazel na lamerske Vista/*buntu/apod. imitace odbornych clanku. -
Mard (neregistrovaný)+1 :-) Asi ne, já už mnoho let používám SUSE (první koupená verze byla 7.0) :-) a tak jsem holt lama. No asi je to proto, že nepřekládám kernel nejméně jednou týdně a též si ani nepíšu s Andrewem Mortonem o tom že parametr /NODEVICE /NOFLOATING při volání funkce jádra je neefektivní :-) Heheheh
-
Seti (neregistrovaný)Jenom by mě zajímalo, jakou rovnováhu. To jako má zase linux vypadat jak v 90. letech nebo co? Mně to naopak vyhovuje, že se nemusím starat o kdejakou ptákovinu, kvůli každé změně rekompilovat jádro a podobně a můžu se věnovat tomu, co mě živí.
Nikdo vám nebrání zůstat u těch distribucí, které vám vyhovují, ale nebraňte ostatním, aby přiblížili linux obyčejným uživatelům. Všichni máte plnou hu... ústa svobody, ale sami ji druhým nedopřejete. -
Palo (neregistrovaný)Je to troll. Podla jeho prispevku vsetko je zle. Vsak nech si vsetko stahuje. Uz aj cisty blazni pochopili ze potrebuju nejaky automatizmus aby sa z toho vsetkeho software nezblaznili. O com inom je Gentoo.
Niekedy na systeme stacilo jadro, VIM a GCC a clovek sa citil spokojny. Dnes toho treba o cosi viac. Od vtedy ako som zacal pouzivat Debian som jadro nekompiloval a nevidim to ako problem. Vsetko okrem nejakych Java programov taham z repository. -
Seti (neregistrovaný)Přesně tak. Nevím, proč kompilovat, když nemusím. Ať si kompilujou na desktopu nadšenci. Mi úplně stačí, když to musím dělat na serverech. Na desktopu kliknu a nestarám se :) Už vidím někoho, kdo spravuje xx desktopů všude možně, třeba i u známých, jak všechny obchází nebo přes ssh stahuje zdrojáky jádra a ovladačů a šplichtí se s tím.
-
Max (neregistrovaný)ale no tak, po instalaci se system nakonfiguruje a pri kazde dalsi rekompilaci kernelu se pouzije jeden jediny prikaz:
/bin/cp -r /usr/src/linux /usr/src/linux-2.6.22.1 && cd /usr/src/linux-2.6.22.1 && /usr/bin/wget http://kernel.org/pub/linux/kernel/v2.6/incr/patch-2.6.22.1-2.bz2 && /usr/bin/bzcat patch-2.6.22.1-2.bz2 | patch -p1 && /bin/cp ../linux/.config . && make oldconfig && make modules && make modules_install && /usr/bin/rm /usr/src/linux && /usr/bin/ln -s /usr/src/linux-2.6.22.1 /usr/src/linux && /sbin/reboot
prikaz muze byt snadno vygenerovan a s pomoci regularnich vyrazu v nem mohou byt upraveny veskere dynamicke hodnoty + take lze snadno rozsirit o automatickou upravu grub.conf (popr. jiny bootmgr.conf) a vsem novym features muzete klidne automaticky priradit N, pokud na ne nemate cas.
Na serverech je potreba kompilovat kernel kvuli bezpecnostnim chybam, ktere se ve starsich verzich nachazeji.
At se na jednom nejmenovanem serveru nauceji pracovat v shellu. -
Max (neregistrovaný)ten reboot tam nepatri, pokud si automaticky nezapisujete neco do boot manageru.
----------
/bin/cp -r /usr/src/linux /usr/src/linux-2.6.22.1 && cd /usr/src/linux-2.6.22.1 && /usr/bin/wget http://kernel.org/pub/linux/kernel/v2.6/incr/patch-2.6.22.1-2.bz2 && /usr/bin/bzcat patch-2.6.22.1-2.bz2 | patch -p1 && /bin/cp ../linux/.config . && make oldconfig && make modules && make modules_install && /usr/bin/rm /usr/src/linux && /usr/bin/ln -s /usr/src/linux-2.6.22.1 /usr/src/linux && /bin/cp arch/i386/boot/bzImage /boot/bzImage-2.6.22.1 && /bin/cp System.map /boot/System-2.6.22.1.map -
LO (neregistrovaný)Ono ho to celé přejde ve chvíli, kdy si uvědomí, že ten skript musí nakrmit současnou a cílovou verzí kernelu. Podruhé ho to přejde, až si uvědomí, že když wget nenajde co hledá, a místo toho stáhne stránku "404 - nenalezeno, ale vyberte si z následujících linků...", tak se to pak bude snažit dál zpracovat. Podobných problémů bude tisíc, a zatím co on je bude řešit, a po takto strávených dnech až týdnech si libovat, že mu to běhá skoro jako Windows NT 3.51 (jen bez aplikací, a chudší na features), ostatní budou pracovat a vydělávat peníze. No a protože práce kvalifikovaného odborníka má cenu několika licencí Windows za den, je lehké si spočítat rentabilitu.
-
Já na Gentoo nic krmit nemusím, mě se pravidelně při updatech stahují zdrojáky aktuální verze kernelu a navíc se ještě vytvoří symlink /usr/src/linux na nejnovější verzi. Už asi půl roku používám triviální skript, který buď zkopíruje .config z /proc/config.gz nebo z poslední verze zdrojáků a spustí make oldconfig (update .config z předchozí verze zdrojáků), nebo spustí make menuconfig (interaktivní nastavení pomocí nabídek), když nenajde žádný použitelný starší .config. Pak všechno zkompiluje a nainstaluje a navrch ještě zkompiluje a nainstaluje všechny externí moduly (ovladače WiFi, Ethernetu a grafiky). Vygenerování GRUB nabídky podle vzoru to samozřejmě umí také. Jediné, co musím udělat, je spustit root terminál, spustit skript, odklepat pár nových nastavení a po 2 minutách restartovat počítač.
-
Kolikrat to jeste clovek bude psat.... no ale budiz:
1. Stabilni API neni politicke, ale ciste technicke (a spravne) rozhodnuti. Jeho zavedeni by rychle ucinilo kernel temer neudrzovatelny, vyvoj by se nesmirne zpomalil a velmi by pribylo chyb. Vice viz /usr/src/linux/Documentation/stable_api_nonsense.txt
2. Vzhledem k cislovani verzi kernelu rady 2.6 jsou 2.6.18 i 2.6.21 "velke" verze kernelu. "Male" verze maji o tecku vice. Nicmene kdyby to bylo treba kvuli oprave chyby, jiste by bylo spravne zmenit API i mezi nimi. -
Mr. Zdeeck (neregistrovaný)Musim nesouhlasit. Nemusim argumentovat ja, muzeme si precist primo Linuse:
- I _want_ people to expect that interfaces change. I _want_ people to know that binary-only modules cannot be used from release to release. I want people to be really really REALLY aware of the fact that when they use a binary-only module, they tie their hands.
Note that the second point [vyse uvedeny] is mainly psychological, but it's by far the most important one.
http://www.uwsg.iu.edu/hypermail/linux/kernel/9902.1/0012.html
Takze _je_ to politicke rozhodnuti. Samozrejme nektere zmeny musi byt provedeny, ale clovek by si pokazde mel rict "je to opravdu nutne?" a ne "no nic, tohle smaznu a at se s tim hosi s ne-jadernymi ovladaci (klidne open-source) poperou po svem".
Uvedomte si proboha, ze tohle zasahuje daleko vice open-source ovladace, ktere nejsou v jadre, nez firmy s binarnimi ovladaci. Vite kolik lidi, co vyrabi ruzne drivery pro USB kamery, exoticky HW, atd. musi pri kazdem releasu jadra venovat svuj volny cas do patchu jenom proto, ze se neco zmenilo? A argument "at si to dostanou do jadra" take neobstoji, protoze tam neco dostat je beh na hodne dlouho trat (viz nektere filesystemy, atd.) -
anonymníVašee odmítavá reakce na předchozí příspěvek je pouze projevem emocí. Z čistě technického hlediska má ten pisatel pravdu. Vámi linkovaný mail od Linuse pak Vaši věc vůbec nepodporuje, neboť je k tématu irelevantní. Linus zde pouze zdůrazňuje, že si přeje, aby všichni věděli, že vnitřní API se budou měnit, aby pak za ním nechodili skuhrat.
To, že se Linus rozhodl vést jádro tímto směrem, bylo zajisté politické rozhodnutí. Avšak z hlediska vývojáře jádra a OS driverů je to technicky nejlepší rozhodnutí. To, že to ztěžuje život vývojářům closed source driverů je jistě nepříjemné, ale z dlouhodobého hlediska pro Linux možná jen dobře. -
Mr. Zdeeck (neregistrovaný)Ne, neni to projevem emoci, ale racionalniho uvazovani. Nekolik let je mym hobby rozchazeni exotickeho hardware pod Linuxem a verte mi, neni nic horsiho nez zmena ABI/API s kazdou verzi. Cetl jste muj dovetek, ze nejde o binarni ovladace (protoze zaplatit programmera, ktery jednou za mesic neco patchne neni napr. pro nVidii opravdu problem), ale daleko vice o open-source, ktere nejsou v jadre?
Podivejte se treba na vyvoj spca50x a jejich Changelog, jak neustale museli neco fixovat, jenom proto, ze se "nahore" (LKDs) bylo rozhodnuto, ze se nejaka funkce zmeni. A to jsou "ti hodni" open source lidi! Ostatne moje prihoda s LIRC nize mluvi sama za sebe.
Z ciste technickeho hlediska pravdu opravdu nema, protoze zpetna kompatibilita je sice balvan na noze pro vyvojare jadra/knihoven/atd., ale odlehceni pro vsechny ostatni, kteri ten konkretni kus SW pouzivaji. Diky tomu, ze nekteri neciti tuhle zodpovednost, se neustale resi problemy typu "no, tak tohle od verze knihovny libxxx-3.10.1a uz nejede, protoze hosi zmenili API, takze si pockejte, az to fixnem u nas". Pokud se neco zmeni v "korenovem" systemu stromu zavislosti, mnozstvi investovane prace vsech ostatnich stoupa geometrickou radou.
Princip je v tom, ze vyvoj by mel byt z vetsi casti evolucni (tj. zpetna kompatibilita) a revolucni (tj. zmena API, principu fungovani, atd.) jenom v pripade, kdy je to nezbytne nutne. -
cedrik (neregistrovaný)Nepamatuji si presne cislo, ale kdyz placnu 82-92%, tak natolik jsou geneticky kompatibilni lide s vetsinou lidoopu (neplest s opicemi, tam je to horsi. Nechytat za slovicka, vsadim boty ze predrecnici mely na mysly lidoopi). Asi ze 47% se zelim.
A ted doufam ze neplacam blbosti, ponevaz si to ted nemam jak overit.
Takze ne plne. Nema nekdo tuseni na kolik procent je si je ABI komatabilni mezi verzemi? -
S simpanzi 96%, do tech 82% by se mozna vesli i ty opice, 20% genu mame spolecnou s E.Coli. Nicmene vsimnete si, ze pres tak velkou shodu neni mozne aby spolu clovek a simpanz meli potomka.
Jinak, co se tyce "par tydnu" ... jadro se za posledni rok zlepsilo mnohem vic nez clovek za poslednich 10000 let. Bude jeste pekne dlouho trvat nez bude jadro tak stabilni jako clovek ... -
A pokračování, které je mnohem zajímavější:
Why? Because I'm a prick, and I want people to suffer? No.
Because I _know_ that I will eventually make changes that break modules.
And I want people to expect them, and I never EVER want to see an email
in my mailbox that says "Damn you, Linus, I used this binary module for
over two years, and it worked perfectly across 150 kernel releases, and
Linux-5.6.71 broke it, and you had better fix your kernel".
See?
I refuse to be at the mercy of any binary-only module. And that's why I
refuse to care about them - not because of any really technical reasons,
not because I'm a callous bastard, but because I refuse to tie my hands
behind my back and hear somebody say "Bend Over, Boy, Because You Have
It Coming To You".
Pokud tohle "politické" rozhodnutí znamená, že se v jádře nemusí udržovat 4 různá USB rozhraní jen aby pár prehistorických binárních ovladačů fungovalo i po 10 letech, tak je to rozhodnutí správné. V jádře je spousta důležitějších problémů než údržba zastaralého kódu.
Ten zásah open source ovladačů mimo jádro není zase tak velký. Až na výjimky se obvykle mění jen drobnosti a upravit ovladač pro nové jádro zvládne každý programátor, který umí používat grep a číst changelog. Pak už záleží jen na tom, jak dobře spolupracují hlavní vývojáři toho ovladače s komunitou. -
Mr. Zdeeck (neregistrovaný)No pockat, ale neni to nahodou presne to, co rikam?
Tj. Linus si zvolil cestu "nechci mit balvan udrzovani API/ABI na svych bedrech", coz je jiste pouze v jeho kompetenci a jeho osobni rozhodnuti a jak sam tvrdi, ze "not because of any really technical reasons". Ja chapu, ze je zpetna kompatibilita je "vopruz", na druhou stranu benefity jsou vice nez znatelne.
Priklad Linuse je, sam uznavam, trosku spatny, protoze je to clovek veskrze pragmaticky. Bohuzel jsou kolem jadra jini (napriklad Greg KH), kteri jsou opravdovi fundamentaliste, kteri chteji dokonce moznost jakehokoli std. ABI znemoznit. 2 mesice zpet kolem toho byla tusim dost drsna diskuze na LKML.
A co se tyka zasahu do okolnich driveru:
Jedna vec je zmena kodu (kterou proste musi udelat vsichni a nemyslim si, ze by byla nejak nicotna), druha vec jsou uzivatele, kteri cekaji, az se patch dostane vubec ven. Jen tak pro ilustraci vypis (baj woko, bez grepu) z Changelogu jiz zmineneho spca50x:
* Fixes for compilation against 2.4.20 kernels
* FIX compilation problem under kernel 2.4.24
* Add usb_kill_urb() for the 2.6.9 kernel
* Re-sync with spca5xx to fix support for > 2.6.5 kernels.
* sync with spca5xx to make it compile with gcc 3.4.3 and to make it work with linux 2.6.10.
* restore the le16_to_cpu() for kernel up to 2.6.11
* FIX from Ulisses De Penna Kernel problem with 2.4.23
* FIX compilation with kernel > 2.6.14
Ja vim, mozna to pro nekoho neni moc (urcite to neni vsechno), mozna pro nekoho ano. Faktem vsak zustava, ze cloveka nenastve nic vic, nez ze po upgradu kernelu se musi prekompilovat X modulu, z nichz pulka ani nejde, protoze se ceka na fix. -
Mr. Zdeeck (neregistrovaný)No samozrejme, ale:
1) opravim si to sam a cekam, az to bude ofiko
2) musi si to opravit jini a cekaji, az to bude ofiko
3) a nakonec to opravi autor driveru a je to ofiko
Takze jsme na tom delali vlastne vsichni -> plytvani zdroji. Jiste, autorovi muzu poslat svuj patch, ale ten ho opet musi projit, udelat si to "po svem", takze zase prace navic.
A uvedomte si take, ze ne vsichni jsou si schopni neco sami opravit. Samozrejme je zde nekde vyse uvedeny argument "Linux neni pro BFU", a pokud tomu tak opravdu je, muzeme klidne diskuzi utnout, protoze ne-BFU si to fakt mohou opravit sami, o tom nepolemizuji. A hazet vsechno na spravce distribuci (jak nekdo nahore navrhoval) mi pripada jako presouvani problemu z jednoho cloveka na jineho. -
Petr (neregistrovaný)Umim instalovat a spravovat domeny, nadnarodni site, politiky, clustery a libovolne sluzby jak na Win tak na Linuxu. Presto kdyz je ve zdrojaku neco rozbite a nejde to zkompilovat, tak to vetsinou neumim opravit (vlastni rukou), protoze mne programovani nikdy nebavilo a kaslal jsem na to. Takze jsem podle teto definice asi BFU. Takovou logiku miluju.
-
hacko (neregistrovaný)Z pohledu vyvojare jadra BFU zcela jiste jsi (jako asi vetsina z nas, co nejsme profesionalni programatori). Nechapu proc se rozcilujes, neni to nic hanliveho.
Az poletis letadlem, taky budes z pohledu kapitana "tamten pasazer vzadu" (ekvivalent BFU), u doktora "tamto vezetpecko" (ekvivalent BFU) a z pohledu pravnika jen "pripad XY" (rovnez ekvivatent BFU). Clovek proste nemuze umet vsechno na svete a proste ve vetsine pripadu vystupuje prave v roli BFU.
To jestli umis konfigurovat site, opravovat servery nebo nejlepe z cele Prahy zpivat karaoke s tim nesouvisi. -
anonymníLoL, pokud si vazne myslis, ze na tom neni nic hanliveho, tak si najdi definici te zkratky a mozna pochopis. Osobne bych taky nikdo nerekl o programatorovi, ze je to BFU, protoze neumi spravovat to co ja. Je to taky odbornik, ale v jine oblasti. Oznaceni "BFU" je proste zcela mimo.
Btw letadlem litam docela casto...i jako pilot :-D -
miro (neregistrovaný)IMHO Bloody Fucking User jsou spíše slova, ze kterých ten akronym vzniknul, v diskuzích se už dávno většinou BFU používá ve smyslu Běžný Franta Uživatel. Akronymy jsou zkrátka praktické a lepší akronym než BFU zkrátka nikdo nevymyslel (nebo se aspoň neujal). BTW já jsem také BFU ;-)
-
Ondrej 'SanTiago' Zajicek (neregistrovaný)> No pockat, ale neni to nahodou presne to, co rikam?
Ty mozna jo, nicmene puvodni prispevek od glx byl ve stylu "kerneli vyvojari meni rozhrani jen proto, aby zkomplikovali zivot vyvojarum closed-source driveru".
Oproti tomu prispevek Linuse ukazuje ten technicky duvod - udrzovani kompatibilty je pracne a komplikuje vyvoj - rozhrani se meni proto, ze vyvojari se pri upravach jadra nechteji svazovat udrzovanim kompatibility. -
Mr. Zdeeck (neregistrovaný)No, ted jsem opravdu zaskocen, protoze jsem si myslel, ze tenhle nazor na ABI mam jenom ja. Kdyz jsem s necim podobnym prisel do diskuze na ABCLinuxu, vsichni mne vyfuckovali big-time :-/
Prihoda z realneho zivota: zrovna vcera jsem si chtel zkompilovat po dlouhe dobe LIRC pro ovladac meho TV tuneru. Samozrejme LIRC neni v jadre (mam Debian-patchset 2.6.22), takze jsem musel rozkompilovat jadro, zacit kompilovat LIRC a ejhle - dva symboly se ztratily z ovladace BT8xx, takze LIRC nejde rozchodit (presneji receno modul lirc_gpio). Samozrejme se ted ceka na vyvojare LIRCu, az si najdou trosku casu a fixnou to. Chybi totiz 2 docela podstatne funkce (get_gpio_queue a get_card_info) a moje pokusy o nalezeni potrebnych informaci nekde jinde v jadre skoncily asi po pul hodine. Kdyby bylo stabilni ABI, byl by svaty klid a nemysel bych kompilovat nejaderne ovladace pokazde po upgradu jadra jak mameluk a modlit se, at se tam proboha nic nezmenilo. -
glx (neregistrovaný)Tento nazor hajim jiz velmi dlouho. Za ta leta jsem dosel k jednoznacnemu zaveru, ze propagatori "nestabilniho" ABI jsou nahony vzdaleni praktickemu zivotu a pohybuji se pouze kdesi mezi ryzimi akademiky.
Podle me je prave toto vec, ktera rozvoj Linuxu brzdi. A brzdi jej velmi silne. Pokud by se Linux tohoto nesmyslu zbavil, razem by ochota vyrobcu hardwaru podporovat Linux stoupla prinejmensim o jeden rad, pribylo by uzivatelu a diky tomu se objevily nektere klicove aplikace v nativni verzi.
Motivaci umyslne "nestabilniho" ABI chapu skutecne cim dal mene. Chapu to skutecne predevsim jako zalezitost jisteho fanatismu a nesmyslneho purismu nekterych lidi. Je to VELKA skoda.
Na druhe strane je obdivuhodne, kolik hardwaru dnes prumerna Linuxova distribuce bez problemu podporuje i pres tuto nesmyslnou prekazku. -
LO (neregistrovaný)To je klasika. Když o něčem tvrdíte, že to není skvělé, nesmí to být Linux nebo na Linuxu. Možná vás (i tady) vyfuckují méně, když začnete slovy "Linux je super, miluji myšlenku open source, ale...", a skončíte slovy "A teď jdu pracovat na GPL projektu, protože je to náplní mého života".
-
anonymníVíte co to je ABI? Zjevně ne, protože jinak byste tu nemachroval s těma pojmama a nepsal kraviny http://en.wikipedia.org/wiki/Application_binary_interface vs http://en.wikipedia.org/wiki/API. Takže ovladače používají kernelovou API a uživatelské programy používají kernelovou ABI. A ano, je pravda, že API se mění. Ovšem s tím se počítá, protože kernel je velice živé maso.
-
anonymníMozna nez zacnete machrovat byste si mohl aspon precist to na co odkazujete a vedel byste, ze to neni tak jednoznacne.
"An ABI differs from an application programming interface (API) in that an API defines the interface between source code and libraries, so that the same source code will compile on any system supporting that API, whereas an ABI allows compiled object code to function without changes on any system using a compatible ABI."
