Linux-2.6.39 + Nvidia-96.43.19 gyári driver telepítése

Debianos srácok előszeretettel próbálják megtartani a klasszikus Linux életérzést, az-az amikor napokat szop az ember, egy-egy problémával.
Egy ideje szívtam az nvidia-96.43.19 gyári driverével, ami rendszeresen SIGTERM-el szállt ki a telepítés elején. Némi molyolás árán sikerült utánajárni a problémának és 2.6.39-el működésre bírni.
Az első lépés, hogy minden repohoz tartozó nvidia csomagot takarítsunk le a gépről.
dpkg -l | grep nvidia
apt-get --purge remove csomagnév

Szedjük le a 2.6.39-et, vagy valamelyik nekünk tetsző kernel forrást a kernel.org-ról, és szedjük le a nvidia-96.43.19-et az NVIDIA oldaláról. Ez utóbbiból a legfrissebbet szerezzük be, mert az Xorg-ék megint belemolyoltak az ABI-ba és emiatt nem fognak menni a régebbi driverek.
Konfiguráljuk, forgassuk, telepítsük az új kernelt a szájízünk szerint. A szokás kedvéért adjuk ki a make oldconfig és a make prepare-t, ez jól jöhet más, régi külső fél által gyártott driverek telepítésénél is.
Indítsuk újra a gépet az új kernellel. Ellenőrizzük, hogy az /usr/src/linux az új kernel forráskönyvtárára mutat.
Állítsuk be a CC változó értékét az épp aktuális C fordítóra (pl. export CC=gcc-4.6) és lőjjük ki az X-et.
És most jön a trükközés. Ha simán elindítjuk a telepítőt, amit ugye nem felejtettünk futtathatóvá tenni (chmod 755), akkor a kernel modul forgatásakor fog kiszállni hibával.
Az ok egyszerű, Linus-ék vidáman kiherélték a kernelből linux/smp_lock.h-t, ez viszont include-olva van a telepítőben.
Tehát, ki kell tömöríteni a telepítőből a forrást:
./NVIDIA-Linux-x86-96.43.19-pkg1 -x
Ez létrehoz, egy ugyanezen nevű könyvtárat, amibe belegaloppozunk és meg sem állunk a NVIDIA-Linux-x86-96.43.19-pkg1/usr/src/nv-ig, ahol megkeressük az nv-linux.h filet és a kedvenc szerkesztőnkkel kikommentezzük a 83-as sorban az #include
részt.
Ezután vissza a NVIDIA-Linux-x86-96.43.19-pkg1 könyvtárba, ahol az nvidia-installer futtatásával a megszokott módon telepíthetjük a drivert. Ellenőrizzük, hogy az xorg.conf-ban jók-e a beállítások és indítsuk újra az X-et. Ha minden jól ment menni fog az X.
glxgears-el vagy glxinfo-val ellenőrizzük a gyorsítás meglétét és kész.

Nálam:
GL_VERSION: 1.5.8 NVIDIA 96.43.19
GL_VENDOR: NVIDIA Corporation
GL_RENDERER: GeForce4 MX 440 with AGP8X/AGP/SSE/3DNOW!
és kőkemény 61 FPS 1440x900-ban,,,

( uid_194 | 2011. 05. 24., k – 00:10 )

gcc-4.6? Csak nem unstable user? Ezesetben megis, mire szamitasz? :>

Ennel sokkal szebb es mokasabb dolgokat is sikerult mar osszehozniuk sidben a nepeknek (udev 169-1 pl egyszeruen zsenialis. Hint: ne probald ki :P).

--
|8]

( BaT | 2011. 05. 24., k – 00:14 )

"és kőkemény 61 FPS 1440x900-ban,,,"

Glxgears? Azzal a kártyával más nem nagyon fut 61fps-en (vsync?). :)

--
Don't be an Ubuntard!

( log69 | 2011. 05. 24., k – 09:22 )

"klasszikus Linux életérzést...napokat szop"

"Szedjük le a 2.6.39-et, vagy valamelyik nekünk tetsző"

ez így erős csúsztatás.

"Debianos srácok előszeretettel próbálják megtartani a klasszikus Linux életérzést, az-az amikor napokat szop az ember, egy-egy problémával. "
Idézni csak szépen, mint ahogy a csillag megy az égen.
Debian érdemei:
-nem szabványos könyvtárszerkezetek és file lokalizációk.
-dependency hell. Különös tekintettel, amikor teljesen értelmetlen, az adott csomag működését nem befolyásoló verziószám problémákra.
-az agyatlan "peace, GPL, és RMS" ideológia miatt megnyomorított, átnevezett alkalmazások.

Ehhez képest a kernel, és annak a forgatása igencsak sokat fejlődött.
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

idézni nem idézem be az egészet, mert 2 centivel feljebb elolvasható. az általam lényegeset emeltem ki.

ettől függetlenül mellé beszélsz. ezeknek semmi köze ahhoz, hogy dev verziót ócsárolsz. értem hogy linus kiadta a 39-est pár napja, de ettől még nem lesz stabilabb. ha disztró által szállított stabil release kernelét szidod, azt elfogadom. gcc 4.6-ról nem beszélve. ugye ez debian unstable?

kezd uncsi lenni ez a szarozás. főleg mikor ugyanannak az embernek a szájából halljuk (nem te) századszor. én úgy vagyok vele, hogy ha valami ennyire szar lenne nekem, biztos nem nyúlnék hozzá tíz évig, de még a topic-okat sem követném erről napi 8 órában.

öregapám mondta mindig, hogy vannak emberek, akik mindig úgy kezdik, hogy hogyan nem jó. amit én látok, hogy vannak emberek, akik ezen nem is lépnek túl (ez megint nem te, más itteni trollokra gondolok). értem hogy miért, csak kár hogy 99%-ban ez van itt.

kieg.: a GPL-hez meg annyit, hogy mondj egyetlen okot, ami miatt jobb pl. a BSD licenc a fejlesztő szempontjából. nem értem itt a GPL fikázást. lehet hogy éppen ez miatt fejlődött sokkal dinamikusabban a Linux, mert vissza kell juttatni a változtatásokat a módosítás után újraterjesztéskor. ez mindenkinek jobb lehet hosszú távon.

miért jó a BSD a GPL-el szemben? erről még nem olvastam jó érvet évek óta itt. (többi licenchez nem tudom most alaposan összehasonlítani, de általában a BSD-vel szemben hozzák fel).

RMS-el meg miért foglalkozol? kit érdekel? nem ő fejleszti a cuccokat, amiket használsz.

Ha, mint fejleszto, arra torekszel, hogy a kododat minnel tobben, minel tobb helyen hasznaljak, properiatry es free kodban egyarant, akkor a BSD licensz merfoldekkel jobb, mint a GPL. Ha nem erdekel, hogy nem kotelezo masnak visszajuttatnia a fejlesztest, ha az erdekel, hogy hasznalja, es elmondhasd, hogy igen, ebben is a te kodod van, akkor a BSD kenterbe veri a GPL-t.

Ha a felhasznalo szabadsaga az elsodleges szempontod, a BSD uti a GPL-t.

Ha viszont azt akarod, hogy a kod szabad maradjon, es a kod szabadsaga tobbet szamit a felhasznalo szabadsaganal, akkor a GPL a nyero. De kb csak ebben az esetben.

--
|8], a gonosz GPL-hivo mano.

de én a "fejlesztő szempontjából" kérdezem.

az, hogy elmondhatja valaki, hogy BSD licenccel talán! többen használják, egyrészt nem megállapítható, másrészt a BSD-vel a különbség csak az újraterjesztéskor számít - használni használhatja bárki, és azt csinál a GPL-es kóddal is amit akar, amíg nem terjeszti újra. na most a kódot módosítva újraterjesztők száma nyilván nem sok, tehát ez nekem nem mérvadó. tehát a felhasználó szabadsága nem kérdés.

úgy gondolom, ezeknél az érveknél is a fejlesztőnek jobb a GPL, mert legalább visszajut hozzá is a módosított kód, ha a cuccát újra terjesztik. meg azért is jobb a fejlesztőnek, mert a GPL-el a közösségnek jobb hosszú távon, tehát ha érdemet nézünk, akkor ezzel jobb lesz a munkája.

ha a BSD kódból saját binárist gyúr egy nagy cég pl., akkor arra épít üzletet, és ezért nem érdeke kiadni a saját módosításait, ami pénzébe került, mert így nyilván előnyhöz jutnának a többiek. vagyis ez nem gerjeszt egy olyan folyamatot, amelynél meg van az esélye, hogy a szoftver egyre jobb legyen, amelyet a közösség használ, és így ők is egyre jobbat használhatnak.

Igen, a fejleszto szempontjabol. Van olyan fejleszto, akinek bokne a csoret, ha nem hasznalhatnak a kodjat properiatry kodban (amit nyilvan terjesztenek is). Nem erdekli, mennyi kodot kap vissza, ha egyatalan kap, mert nem ez a celja. Egesz pontosan magasrol tesz ra.

Az a celja, hogy a kodot barki, barmire felhasznalhassa es terjeszthesse, mindossze azzal a par apro megkotessel, amit a BSD licensz eloir. Akinek ez kell, az a BSD-vel jobban jar, mint a GPL-lel.

Kozossegrol meg ilyenekrol szo nincs. Keves olyan fejleszto van, akit elsosorban ez mozgatna.

--
|8]

attól hogy ezt akarja, még nem látom hogy miért lenne jobb ténylegesen ez a választás (azt leszámítva, hogy úgy van, ahogy akarja). te most a fejlesztő mellett érvelsz, én meg a BSD licenc mellett szeretnék érvet hallani, hogy mitől lenne anyagilag, erkölcsileg, vagy üzletileg jobb választás a BSD licenc a fejlesztőnek.

Ha a licensz meggatolja a fejlesztot abban, amit el akar erni, akkor az a licensz nem megfelelo a fejlesztonek. Ha a fejleszto az altalam vazoltakat akarja elerni, akkor a GPL ebben meggatolja, ergo a BSD jobb neki.

De, mondok par peldat:

- Erkolcsileg azert jobb a BSD a GPL-el szemben, mert sokkal szabadabb felhasznalast biztosit. A GPL sokkal tobb kotottseget rak a kodra, mint a BSD, sokkal jobban limitalja, hogy mikent lehet felhasznalni es terjeszteni. A BSD sokkal szabadabb ilyen szempontbol, mert sokkal kevesebb szabalyt allit fel.

- Anyagilag elonyok: tegyuk fel, van egy kodod, amibe erkezik kulso fejlesztes. Copyright assignment es hasonlo nincs, igy az uj kod copyright holdere nem te vagy. Innentol kezdve nem tudod relicenszelni a kodot. Tegyuk fel, hogy szeretned sajat, properiatry kodban felhasznalni ezt a 90%-ban altalad fejlesztett kodot. Ha GPL a licensze, nem tudod megtenni, mert 10% GPL kodnak nem te vagy a tulajdonosa, es a copyright holder nem feltetlenul fog hozzajarulni ahhoz, hogy a kodjat felhasznald !GPL alatt. BSD licensz eseten nincs ilyen gond, mert ezt megteheted. Igy anyagilag jobban jarsz, mert nem kell idot es veszodseget feccolnod abba, hogy megoldd a problemat.

- Uzleti elonyok: Ha non-free kodot ir az ember, akkor a BSD nyilvan messze elonyosebb, remelem ezt nem kell magyaraznom, miert.

Kulso fejlesztonek, aki nem a kod eredeti gazdaja, a BSD sokkal tobb lehetoseget enged, mint a GPL, ezert neki az sok szempontbol jobb lehet.

A kod fejlesztojenek szinten nyujt elonyoket a BSD licensz, lasd fentebb.

Az egy teljesen masik kerdes, hogy ki mennyire ert egyet ezekkel a celokkal es elvekkel.

--
|8]

"Erkolcsileg azert jobb a BSD a GPL-el szemben, mert sokkal szabadabb felhasznalast biztosit..."

ez nem jó érv nekem. ezzel nem jobb a közösségnek, a fejlesztőnek meg mint írtam, csak az újraterjesztésnél számít.

"Anyagilag elonyok: tegyuk fel, van egy kodod, amibe erkezik kulso fejlesztes. Copyright assignment es hasonlo nincs, igy az uj kod copyright holdere nem te vagy. Innentol kezdve nem tudod relicenszelni a kodot..."

az újra licencelés nem cél szabad szoftvernél, illetve ha valaki szeretne zárt részt terjeszteni belőle, akkor nem fogad el hozzájárulást -vagy másképp, de ez már egy másik sztori.

"Kulso fejlesztonek, aki nem a kod eredeti gazdaja, a BSD sokkal tobb lehetoseget enged, mint a GPL, ezert neki az sok szempontbol jobb lehet."

Neki, de nem az eredeti fejlesztőnek. A cél szerintem nem egy másik fejlesztő támogatása anyagilag az ingyen munkával úgy, hogy ő zártként tudja terjeszteni. Ettől még mindig nem jobb ténylegesen a BSD licences fejlesztőnek, sem a közösségnek.

> ez nem jó érv nekem. ezzel nem jobb a közösségnek, a fejlesztőnek meg mint írtam, csak az újraterjesztésnél számít.

Neked lehet, hogy nem jobb. Sokan vannak, akik viszont pont ezert valasztanak BSD licenszt, mert az o elveikhez ez all kozelebb. A kozossegnek meg jobb, mert BSD eseten a kozossegbe potencialisan a non-free szoftver fejlesztok is beletartoznak, mig GPL eseteben nem. BSD tobb ember szamara hasznalhato, potencialisan nagyobb a kozosseg => jo.

> az újra licencelés nem cél szabad szoftvernél

Nem mindegyiknel. Vannak olyan alapvetoen szabad szoftverek, amelyeket appliance kereteben zartan is terjesztenek. Ezesetben a BSD licensz uzletileg es anyagilag is jobban megeri.

> illetve ha valaki szeretne zárt részt terjeszteni belőle, akkor nem fogad el hozzájárulást -vagy másképp, de ez már egy másik sztori.

Na, mint fejleszto, ezt a reszt szeretnem nagy hahota kozott visszadobni. Mint fejleszto, akar BSD akar GPL parti az ember, az esetek tobbsegeben szeretne, ha kivulrol is erkezne fejlesztes, vagy legalabbis nem zarkozna el elole. A CLA es hasonlok ezt igen erosen gatoljak, ergo ha a licensz miatt erre szukseg lenne ahhoz, hogy a ceg, vagy a fejleszto zart formaban is tudja terjeszteni a programot, akkor a licenszt a ceg/fejleszto nem fogja szeretni.

Ezert (sem) szeretik a nagy cegek a GPL-t annyira.

> Neki, de nem az eredeti fejlesztőnek. A cél szerintem nem egy másik fejlesztő támogatása anyagilag az ingyen munkával úgy, hogy ő zártként tudja terjeszteni. Ettől még mindig nem jobb ténylegesen a BSD licences fejlesztőnek, sem a közösségnek.

Megint GPL-szemuvegben nezed a problemat, es nem vagy kepes atlatni, hogy van aki maskepp is gondolkodhat. Vannak, akiket baromira nem erdekel a szabad szoftver kozosseg. Oket a szoftver kozosseg erdekli, hogy minnel tobb helyre eljusson a szoftvere, zart vagy nyilt, tokmindegy. A BSD licensz ebben tobbet segit, mint a GPL. A fejlesztonek azert jobb, mert konnyebben eleri vele a celjat. A kozossegnek meg azert, mert tobb szereplo tartozhat bele ebbe a kozossegbe, mint GPL eseten.

--
|8]

a non-free fejlesztőket / fejlesztést hozod fel érvként. elfogadom, de akkor úgy fordítom amit írsz, hogy ha non-free-hez is van köze a projektnek, akkor inkább BSD. ha nincs non-free-hez köze, akkor még mindig nem látok érvet GPL ellen és BSD mellett. de elfogadom amit írsz. csak ez innétől nézőpont kérdése.

A licensz valasztas eleve nezopont kerdese.

Es non-free-t leszamitva, tovabbra is ott van az, hogy a BSD licensz tobb jogot hagy meg a felhasznalonak, igy ilyen szempontbol sokkal szabadabb lesz a szoftver, mint GPL alatt. Hogy ez kinek mennyire tetszik, az szinten nezopont kerdese. A magam reszerol belatom, hogy BSD alatt tenyleg szabadabb lenne a szoftverem, de konkretan teszek ra, mert GPL hivo vagyok :P

--
|8]

illetve még annyit had tegyek hozzá, hogy bizonyos esetekben megértem a BSD-hez hasonló engedékeny licencek létjogosultságát, pl. egy alacsony szintű library-nél, vagy egyéb algoritmusoknál a széles felhasználást lehetővé téve.

én a fentiekben nagyobb saját szoftverre gondolok, amelyek nem apró komponensek, hanem egyedülálló szoftverek, ahol a megírt szoftver a nagyobb érték (mint befektetett munka), nem pedig a mögötte álló elméleti probléma megoldása.

> én a fentiekben nagyobb saját szoftverre gondolok, amelyek nem apró komponensek, hanem egyedülálló szoftverek, ahol a megírt szoftver a nagyobb érték (mint befektetett munka), nem pedig a mögötte álló elméleti probléma megoldása.

Ezesetben a BSD-nek az a nagy elonye, hogy engedekeny. Ha van erre a szoftverre epulo non-free verziod peldaul, akkor GPL eseten a kulso fejlesztesek komoly akadalyokba tudnak utkozni: mert ahhoz, hogy azt a non-free verziodba atvedd, copyright assignment vagy hasonlo papirmunka szuksegeltetik. BSD eseten pedig nem, ami sokkal konnyebbe teszi az ember dolgat, es tobb haszonnal jar.

Peldaul itt van az X, ami MIT licenszu (ami majdnem ugyanaz, mint a BSD). Mivel MIT licenszu, el lehetett adni properiatry X szervereket, meg libeket, stb. A mai napig vannak non-free X szerverek, amiket penzert ertekesitenek. Ha GPL lett volna, akkor ezt nem lehetett volna megtenni, ami a fejlesztok megelheteset jelentosen rontotta volna.

--
|8]

Ha nincs erre epulo non-free verziod, es semmi penzed nincs a szoftverbol, akkor akar public domain is lehetne, vagy akarmilyen mas licensz, mert neked, szemely szerint, semmi hasznod nem lesz belole.

(GPL ugyan eloirja, hogy ha modositott verziot terjesztenek, akkor a modositast is kozze kell tenni, de ettol meg nem jartal jobban. Konnyen lehet, hogy pont amiatt mas alternativa utan nez valaki. BSD ezt nem irja elo, de nem is gatolja meg, es igen sok esetben ott is visszajut a modositas, mert a cegeknek konnyebb az, ha nem kell egy forkot karban tartaniuk.)

--
|8]

Peldaul azert, mert a BSD eloirja, hogy a copyrightot mindenkepp meg kell tartani, es binaris formaban is elerhetoen meg kell jeleniteni, valamint a harmadik pont jelzi, hogy engedely nelkul nem reklamozhatjak (+ egyebek) a szarmaztatott termeket a te neveddel.

Public domain ilyen megkoteseket nem tartalmaz. Vagyunk paran, akik nem szeretnenek egy nap arra ebredni, hogy csoda tortent es vilaghires lett, de mindenki utal minket, mert valami kocsog spammer a mi smtp libunket hasznalja, es nagyerokkel hirdeti, hogy "HIIIIIIIIII EZT BIZONY AZ A HIRES FICKO IRTA! LOL!". (Nyilvan erosen sarkitott pelda, de remelem ertheto az elkepzeles :).

--
|8]

Egek...
1. Squeeze van a gépen, a repo kernellel a repo legacy csomag elhasal. Ezért is kezdtem el foglalkozni a gyári driverrel és a mainline kernellel. Nincs sem időm, sem türelmem, hogy az elbaszott csomagkezelést is debugoljam.
2. A Linus-ék mainline kerneljével nem volt semmi probléma, ugyanis ha figyelmesen olvasol, akkor láthatod, hogy a gyári nvidia elavultságával van a probléma. Feltételezem, hogy az 1.-es pont hibája a két csomag karbantartója közötti kommunikációs hiba miatt van.
3. A gcc-4.6-ot példának írtam. Napi szinten vagy féltucat gépet használok, különféle disztribúciókkal, nem kéne a sorok között is olvasni.

Ezer örömmel használnék én mást is, de nincs más és különféle munkáimhoz ezt kell használnom. Jelen pillanatban a Debian felel meg a legjobban az általam használt architektúráknak, de ettől még nem kell szeretnem.
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

> -nem szabványos könyvtárszerkezetek és file lokalizációk.

Mint pl?

> -dependency hell. Különös tekintettel, amikor teljesen értelmetlen, az adott csomag működését nem befolyásoló verziószám problémákra.

Ezt lehet reportolni. Esetek tobbsegeben azert van igy, mert senkit nem zavar, es ha eleg ember nyafog, hogy jo lenne esetleg ket kulon reszre vagni valamit, akkor ket kulon reszre is vagjak. (Vagy atmegy Recommends:-be a stuff fele).

Szivesen latnek erre peldat, ellenpeldaval, hogy mas distribekben hogyan van ugyanaz a csomag megoldva.

> -az agyatlan "peace, GPL, és RMS" ideológia miatt megnyomorított, átnevezett alkalmazások.

Mint peldaul? Persze, van par dolog ami .dfsg, mert a licensz nem engedi meg, hogy mainben legyen az alkalmazas kis irtas nelkul. Az esetek 99%-ban ez egyebkent nem jar erezheto funkcionalitas vesztessel.

Egy masik eset amikor trademark es egyeb policyk miatt van atnevezodes (pl mozilla-*), amiert okold upstreamet.

Harmadik kategoria amikor szabadalmak miatt marad valami ki, ami szinten nem a Debian sara.

--
|8]

"Mint pl?"
A gyári kernel treet, három különálló könyvtárra bontja, /usr/share-be mozgat rendszer komponenseket, stb.
"Mint peldaul?"
wodim->cdrecord
firefox->iceweasel
mplayer kodekek hiánya, ffmpeg mp3 encoding hiánya, stb.
Nem érdekelnek egy kifogások, ha egy alkalmazást szállítanak, akkor azonos névvel, teljes funkcionalitással tegyék.
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

> A gyári kernel treet, három különálló könyvtárra bontja, /usr/share-be mozgat rendszer komponenseket, stb.

Ezt kifejthetned reszletesebben. Nalam a linux-image-2.6.32-5-amd64 /boot, es /lib konyvtarakat tartalmaz, pont mint az upstream make install utan.

Van ugyan benne /usr/share/ alatti resz, de az egyreszt az /usr/share/doc, masreszt az /usr/share/bug, ami a debianos reportbug cuccai.

> wodim->cdrecord

cdrecord package nincs. A wodim pedig != cdrecord, annak egy forkja. Kulonallo dolog.

> firefox->iceweasel

Mozilla trademark policy miatt nem lehet a Firefoxot firefoxnak hivni, ha az ember modositotta, es nem kapott ra kulon engedelyt. A Debian nem kapott, es modositotta.

Panaszkodj a Mozillanal, mert ok hoztak ezt a dontest, a Debian nem tehet mast, kenytelen kovetni. Eredetileg firefox csomag volt Debianban is, de upstream jelezte, hogy ez neki nem tetszik.

> mplayer kodekek hiánya, ffmpeg mp3 encoding hiánya, stb.

Panaszkodj a szoftver szabadalmakat engedelyezoknel.

> Nem érdekelnek egy kifogások, ha egy alkalmazást szállítanak, akkor azonos névvel, teljes funkcionalitással tegyék.

Es fizeted a perkoltsegeket? Ha igen, akkor jelezd Debian fele, szerintem orommel fogadnak a hirt.

--
|8]

pl. /usr/share/alsa-base/snddevices egy script aminek /usr/bin-ben lenne a helye.

cdrecord fejlesztője megtiltotta, hogy az általa fejlesztett kódot a forrás terjesztésen kívül bármilyen formában is megváltoztassák. Ennek az oka az volt, hogy a Debian maintainerek belenyúltak a kódba és emiatt a fejlesztőnél sírtak a userek a bug miatt. A dolog elmérgesedett és végül fork lett belőle. Ennek ellenére a hosszú ideig a cdrecord csomag úgy szerepelt, hogy egy link a wodimra mutatott és a userek továbbra sem tudtak cd-t írni, sőt emiatt a xcdroast is hasznavehetetlenné vált.

A mozilla esetében detto ugyanez a történet. Zongorázható teljesítménykülönbség van az Iceweasel és a Firefox között, vajon miért?

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

> pl. /usr/share/alsa-base/snddevices egy script aminek /usr/bin-ben lenne a helye.

Miert? Upstream make install nem is telepiti sehova, nemhogy /usr/bin-be. Az RPM csomagok dokumentaciokent kezelik, es /usr/share/doc/ ala rakjak be. A script egyebkent ranezesre arra valo, hogy mindenfele alsa deviceokat csinalgasson nekem, tehat ha barhova, akkor /usr/sbin -be kene rakni.

De annak sem latom sok ertelmet, mert ez nem olyan program, amit a felhasznalo rendszeresen elindit, es hasznal: ez egy helper script, amivel egyszer megcsinalod a deviceokat, es viszlat. Tovabb nincs ra szukseg.

Lenyeg a lenyeg, semelyik masik disztribucio (es upstream se) teszi $PATH-ra a kerdeses filet. Upstream nem is teszi sehova, az rpm csomagok doc ala teszik, Debian meg oda, ahova. Ha nem tetszik, reportbug alsa-base, es megprobalhatod meggyozni a maintainert, hogy miert erdemes olyan helyre tenni a scriptet, ahol semelyik masik distribben nincs.

> cdrecord

Ez azert nem teljesen igy esett. Javaslom keresd ki a megfelelo listakon a tortenetet, mert bar Schilly igy meseli a tortenetet, nem pontosan ez tortent. Teny hogy voltak komoly nezetelteresek schilly es a debianosok kozott, de ilyen elmergesuleshez azert ket ember kell.

Ehhez ujra kene olvasnom a regi flamewart, amihez most nem erzek nagy ingerenciat.

(FYI, anno, amikor ez a vita kitort, a cdrecord nalam egesz pontosan nem mukodott debianos patchek nelkul, ami Schillynek annyira fajt.)

> mozilla

Lenyegtelen, hogy miert kerult bevezetesre a trademark policy, a masik fel vezette be, erosen ketlem, hogy csak azert, mert nem tetszett neki, amit Debian csinalt. De van ilyen, es nem lehet firefoxnak hivni a csomagot. End of story.

--
|8]

Azért mint debian használó, hadd szóljak ellenpéldákkal is.

Pl. a dropped lirc_gpio . Ha én mint egységsugarú fizikai dolgozó ki tudtam kupálni, hogy működjön (csak már nem emléxem a pontos megoldásra,
valami nagy gányolás Oscon módra, de leszarom), akkor szvsz kicsit gáz, hogy az a hivatalos megoldás, hogy dropped support.

2. mplayer/mencoder codecek. Jó, szoftver szabadalmi izé, de most lehet hogy hülyeséget mondok,
de nem ezért van a "non-free" szekció ? abban sem férne el ? Hogy lehet, hogy marillatnál a debian multimediaban meg mégis megfér ?

3. vice. Mi a radai retekér' van odaláncolva a gnome-hoz ?
Ha én pusztán a kde-t szoktam meg 2001 (?) óta, x11 videó móddal újra kell forgatnom ,
különben segfaultol a "gnomevideó"-nál. (!) Ez asszem etch óta van így, ha jól emlékszem.
Azt már nem is mondom, hogy hangeszköz inkább "arts" ( ha már kde), mint oss. :-)
Újra tudom forgatni, nem arról van szó, megvan a configfájl etch óta - nem is tart így sokáig -, de te hoztad fel,
hogy szeretnél példát. Akkor tessék !.
Ha a ROM filek azért nem férnek be, mert asszem ahhoz rendelkezni kell olyan C64el pl. ami a szekrényben van, akkor OK, azért nem szólok.

4. grsecurity. Most vagy legyen, vagy ne legyen, valamerre mozduljunk el. De amikor a grsec 2.6.32.13-as verzióval van,
a kernel linux-source-2.6 (1:2.6.32+29)] lehet, az egy kicsit már azért gázos, főleg, hogy a 2.6.32-t
a grsecesek gyakorlatilag helyből szinte kulcsrakészen supportálják.

Tehát nem úgy van, mint anno a 2.6.27esnél, hogy valameddig eljutott a dolog, aztán tartsd karban magad, ha akarod, grsec hivatalosan feljebb lépett a kernelranglétrán.

Igazából mikor néztem a 2.6.32-t egy vagy két kivételtől eltekintve csak
akkor akadt össze a debian patchsettel, mikor egy vanilla kernel sec. bug javítása bekerült a debian patchset be is, és a grsecesek is a saját patchsetükben javították.

Ezek nem panaszkodások, de te kértél példákat.

5. Ellenpélda, nekem kifejezetten tetszik a debian féle kernel forgatósdi, csomagolósdi, lehet azért, mert már megszoktam az évek alatt.

--------

Nem vezetek...Jobb így. Nekem is
meg mindenki másnak is.

> Pl. a dropped lirc_gpio . Ha én mint egységsugarú fizikai dolgozó ki tudtam kupálni, hogy működjön (csak már nem emléxem a pontos megoldásra, valami nagy gányolás Oscon módra, de leszarom), akkor szvsz kicsit gáz, hogy az a hivatalos megoldás, hogy dropped support.

Azt is vedd hozza, hogy ha nincs senki, aki foglalkozni akarna, vagy tudna vele, akkor esszerubb nem azt tettetni, hogy tamogatjak, amikor nem is.

Nem egy dolog kerult ki debianbol azert, mert nem volt vallalkozo szellemu jelentkezo, aki hajlando lett volna foglalkozni vele.

> 2. mplayer/mencoder codecek. Jó, szoftver szabadalmi izé, de most lehet hogy hülyeséget mondok,
de nem ezért van a "non-free" szekció ? abban sem férne el ?

Nem, a non-free nem erre van. Attol, hogy non-freeben van, meg licenszdij koteles lenne a dolog, stb. Non-free annak van, aminek nincs forrasa, vagy egyeb licensz problemak miatt nem kerulhet main-be. Szabadalommal vedett es hasonlo modokon erosen herelt dolgok oda sem kerulhetnek be, teljesen jogosan.

> Hogy lehet, hogy marillatnál a debian multimediaban meg mégis megfér ?

Gondolom o nagyivben tesz ra, es tul kicsi hal ahhoz, hogy foglalkozzanak vele.

> 3. vice. Mi a radai retekér' van odaláncolva a gnome-hoz ?

GTK-hoz van. Gondolom azert, mert az a default, es nem volt (bejelentett) igeny arra, hogy legyen vice-x11 is. Megneztem a debianos bugreportokat, nem talaltam olyat, ami kerte volna, hogy legyen gtk mentes csomag is.

Ha ennyire zavar a GTK, akkor etch ota kuldhettel volna egy bugreportot, es mara mar tobb mint valoszinu, hogy vigan orvendezhetnel egy vice-x11 csomagnak.

Hirtelenjeben atnezve a buglistet nem talaltam olyan hibajelentest, ami az altalad megjelolt gnomevideos segfaultos hibat irta volna le, tehat vagy nem hasznalja mas rajtad kivul a vicet, vagy nem jon naluk elo. Mindenesetre ha a maintainer nem tud ilyen problemarol, akkor nem is tudja javitani.

Olyan miatt sirni, amirol az ember meg bugreportot sem kepes kuldeni, szerintem nem fair ;)

@arts/oss: Bugreport itt is sokat tud segiteni. Foleg ha mukodo config/pelda/akarmi is megy vele. Azzal lehet dolgozni.

ROM-okrol: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=130474 (tobbek kozt)

Feltetelezem licensz problemak miatt nem lehetnek debianban.

> 4. grsecurity

Ezugyben nem vagyok kompetens, igy nem tudom kommentalni.

--
|8]

Mint említettem nem panaszkodásképpen volt / mivel mindegyikre van megoldás /, de ne tegyünk azért úgy, mintha minden abszolút rendben lenne, és problémamentes.

Az X11 az etch alatt asszem egy libx11 frissítés után ment ki, a 2.2ben meg fordítási problémák voltak az x11videoval, valami apróság miatt, már nem emlékszem, hogy mi volt.

Ha olvastad a vice bugokat az arts/x11 kombó használata amúgy megoldja a teljes képernyővel, ill. a hang+teljesítménnyel kapcsolatos problémákat sdl használata nélkül (is), úgyhogy lehet erőltetni a gtk-t (-enable-gnomeui), hogy "default", de vannak következményei.

--------

Nem vezetek...Jobb így. Nekem is
meg mindenki másnak is.

( nanto | 2011. 05. 24., k – 09:29 )

Arch is dobta a legacy 96 es 173 nvidia drivereket, mert eselytelen mukodesre birni az uj Xorg verziokkal. Lassan az nVidia es az ati szerepet cserelnek Linux driver tekinteteben, ha igy folytatjak, ugyanis egyre tobb pozitiv tapasztalatrol hallok uj Ati eseten (arrol nem is beszelve, hogy az xf86-video-nouveau sehogy se all az xf86-video-atihoz kepest)

( blueghost | 2011. 05. 24., k – 14:32 )

Kösz a leírást, ez még jól jöhet.

( Oscon | 2011. 05. 24., k – 22:28 )

A debian mióta olyan friss, hogy 2.6.39-el jön ki ? Ez nekem új (!)

Ha már mindenképp 2.6.39, akkor szerintem a debian középtávon se volt túl jó döntés, de te tudod.
Nem nagyon szokott zökkenőmentesen ketyegni, a legújabb holnaputáni göncökkel.

-------------

A csomagolt debian nvidia / lenny alatt, de szerintem később is /
kétfelé daraboltan műküdik, van az opengl binary modul (xorg) ami verziószám szerint függ a hozzávaló kernel modultól.

Ha csak a kernel modult frissíted, a xorg köszöni szépen verziószám eltérés miatt kiszórja a francba,
és angolosan elköszön. ;-)
Ilyenkor valóban a nvidia gyári telepítő kell, az meg hogy a legacy nvidia 96.43as driver
(C) (www.nvidia.com) nem fordul alapból a 2.6.39en az gondolom nem a debian sara. ;-)
Talán meg merem kockáztatni, hogy kb. senki nem tesztelte a
régi legacy drivert az újdonatúj csodakernelen ;-)

De mintha lenne a debianban gyári legacy driver a gyári 2.6.32es kernelhez, nem ?

Bár az mintha .18 lenne és nem .19, nem lehet, hogy ez volt a sigterm forrása (?).
A .19es kernel driver a .18as debianos nvidia opengl modullal (?)

Szerk: Hja most olvasom, szóval nálad ez hasalt el, érdekes. pfff.

-------

Amúgy, te csak ne panaszkodj,
ez még semmi ahhoz képest, amit a lirc-hez kellett gányolni ;-)

Tőmondtatban a debian "javítás" anno abban kimerült, hogy dropped lirc_gpio support, és pont.

-----------

Debianos srácok előszeretettel próbálják megtartani a klasszikus Linux életérzést,
az-az amikor napokat szop az ember, egy-egy problémával.

Igen, ez egy-egy csomagnál szerintem is jellemző a debianra, hogy az alap beállítás/telepítés - kb (?) -
használhatatlan adott körülmények között,
és az adott csomagot vagy külső forrásból kell beszerezni, vagy újra kell fordítani más opciókkal,
vagy valami spéci konfigurációs fájlt kell szerkeszteni egy-két helyen.

Ha sok ilyen csomagod van, akkor a debian val'szeg nem neked való.
Ha csak egy-kettő, akkor érdemes elgondolkodni,
hogy megéri e a gányolás a befektetett időt, cserébe azért hogy utána kb. rohadásig gond nélkül megy a cuccos, vagy sem.

Nálam most 1081 csomag van telepítve, ebből 7 vagy 8 ami saját fordítás, vagy külső forrás, vagy valami extrém gányolás,
amire már tavaly sem emlékeztem - mert a lényeg, hogy működik, a többitkinemszarjale - nemhogy most.
De nekem pl. megérte. Igen, ez itt a reklám helye :-D
Ha neked nem, széles a disztribúciós paletta, és
ugye a linuxhasználat sem törvényileg kötelező. :-)

--------

Nem vezetek...Jobb így. Nekem is
meg mindenki másnak is.