hulyek @ lkml

linux desktop eve, persze. ilyen nyilatkozatok utan hagyjuk mar, NVIDIA helyeben en kivagnam a francba az osszes linux supportot, es hivatalos kozlemenyben megkoszonnem coxnak ;)

( hrgy84 | 2012. 10. 13., szo – 11:02 )

Ezt az egesz GPL - non-GPL baromsagot kar volt bevezetni, hulye licenchuszarkodas az egesz, aztan mindenki csak szop miatta.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

latom, nem erted a problemat. itt nincs sok valasztasuk, nem tudjak hasznalni, mert jogilag megszivjak amugy. GPL alatt nyilvan nem fogjak kiadni a cuccukat, igy ket lehetseges kimenetel van:
1, lefejlesztik maguknak propriertaryval
2, nem fog menni linuxon, v ha igen, a teljesitmeny szar lesz

ez neked jo, mint linux juzernek?

Nem errol van szo. Hasznalni hasznalhat. Viszont minden derivative work GPL licencu lesz automatikusan ("You may convey a work based on the Program, or the modifications to produce it from the Program...The work must carry prominent notices stating that it is released under this License"). Plusz GPL eseten ha terjeszted a szoftvert, ki KELL adnod a forraskodjat. Ez a nem mindegy.
Maganhasznalatra nyilvan tokmindegy, a GPL a terjesztesre helyezi a hangsulyt.

Szerk. Igazabol nincs olyan a GPL szerint, hogy GPL licencu kodot felhasznalo, nem GPL licencu szoftver. A GPL "ragalyos" olyan ertelemben, hogy minden GPL kodra epulo kodnak GPL-nek KELL lennie.

Értem. Tehát arról van szó, hogy az nvidia-nak bele kéne ágyazni a driver-ébe a kódot.

Viszont nem lehet azt csinálni, hogy csak a kód zárt részét terjesztik, és írnak egy scriptet, ami az user gépén helyben összelinkeli a GPL kóddal?

Szerk:

Még az sem baj, ha módosítaniuk kell az intel drivert, hiszen a módosítást kiadják GPL alatt.

Vagy attól is GPL valami mert össze lehet linkelni egy GPL kóddal? :)

Szerk2:
Vagy ha igen, bánom is én, találjanak ki egy licenszt ami majdnem olyan mint a GPL, kivéve azt hogy össze lehessen linkelni zárt driverrel. Ugyan mit veszítenek? Egy kis kreativitást már!

Hat, a kernelrol magarol konkretan nincs velemenyem, mert nem ismerek minden egyes cuccot benne. Azzal a reszevel van bajom, amivel napi szinten talalkozok, mert igencsak kivannivalot hagy maga utan a minosege.

A Nouveau pl. nagyon hosszu es sok fejlesztes utan is fos. Igy-ugy promotaljak, hogy milyen jo, es az elso ket nap meg tenyleg jo is, aztan amikor elkezdened ugy istenigazabol hasznalni, akkor jonnek az artifaktok, a quick freeze-k, a komplett fagyasok, a kernelpanikok. Tehat nem az a baj, hogy nem tud mittomen videogyorsitast, hanem kepminosegben szarabb, mint egy normal VGA driver. Es ez ultragaz.

Aztan se a KVM se a Xen nem igazan a bugmentessegerol hiresult el. Nem veletlen, hogy a nagyobb gyartok meg egyaltalan nem mentek el a 3.x -es kernelsorozat fele. Ugy ertem, akik virtualizacios termeket gyartanak.

De ez csak ket kiragadott pelda volt, van sok. Az ujabban letilthatatlan automata RAID osszeallitastol kezdve a meg mindig nyugos es vudunak szamito FB felbontasbeallitason at nagyon sokmindent lehetne felhozni. Csak nem akarok.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Csak erintolegesen van koze. A Nouveau pl. azert szuletett meg, merthat ugye a nvidia zart, a kernel meg szivatja szegeny zartforrasu drivereket, kovetkezeskepp a minosege hagy kivannivalot maga utan. A problema ott van, hogy a Nouveau minosege tobb kivannivalot hagy maga utan.

De nem is a licenccel van itt baj, hanem a hozzaallassal. Az pedig csak tetozik a licencben.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Az ok ennel joval egyszerubb: a BSD nem tudott elterjedni sem desktopon, sem pedig szerveren. Igen, tudom, hogy sok BSD-s szerver van - de ez meg mindig borzasztoan keves. Aminek itt piaca van, az a Linux. A gyartok pedig erre oszpontositanak.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Épp egy migrációs folyamat közepében vagyok, ahol Virtualbox -> KVM irányban zajlik a dolog (Ubuntu 12.04).

Semmi speciális dolog - pl. live migration - nem kell, csak annyi hogy stabil legyen WS és random Linux disztróval.

Pofátlan leszek: tudsz valamit mondani, mit érdemes elkerülni?

En is pofatlan leszek: az Ubuntut - enkomplette.

Ha mar KVM, akkor CentOS. Ha valahol, hat ott biztos stabil, tekintve hogy a RedHat az egyik legnagyobb contributora a KVM-nek.

Egyebkent a KVM-mel a kezdeti nehez ismerkedes utan nincs melyebb tapasztalatom, mert elriasztott. En Xen-es vagyok, ha igazan stabil rendszerre vagysz, ahol semmi se bonyolult, csak mukodik, akkor Citrix XenServer. CentOS alapu, az alaprendszer egy nagyon stabil valami, sosem volt ra panasz. Nalunk a gepek is csak akkor szalltak el, ha pl. a mogottes SAN eppen csunyan kohogott.

A XenServer ellen most mar a Windows-only XenCenter sem erv, mert van hozza tok jo webes felulet, ahol lehet a gepeket bokdosni, ujrainditani, konzolt kapni rajtuk.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

O, a tesztek alatt nekunk is jol teljesitett az Ubuntu. Aztan jottek a szopasok. Sajnos nem beszelhetek tul sokat rola, annyit mondhatok, hogy rengeteget szivtunk az instabil kernelukkel.

Erdekes egyebkent, hogy az Ubuntus szervereknel olyan 70-80%-ban a kernel szokott szar lenni. Legalabbis amikkel en talalkozok. Sajnos a KVM meg a Xen eleg kernel-intenziv dolog...
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

"Ugyan mit veszítenek?"
Mindent. Mar a nem GPL licensu API reszek letezese is nagy engedmeny.
Eleg jol menek az Nvidia harverek, megis a kernel halalozasok egyik fo oka. Sokan nem szeretik, ha valami olyasmi oli meg rendszert, amit nem tudnak megjavitani, mert zart licensu.

Ha drivereket beengednek nem GPL kompatibilis licensel, az a zart driverek elszaporodasat jelenti, ami sok "megoldhatatlan" problemat jelent.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Igy viszont szopatjak a driver gyartokat - akik nem biztos, hogy szeretnenek szopni - kevesebb energiat fognak fektetni a Linuxos driverekbe. Ez egy ordogi korhinta, es nem egyszeru rola leszallni. A kernelfejlesztoknek is kellene lepeseket tenni.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Nem.

Nvidia bemutaogatos esemeny utan, felvetotodott (kernel reszrol), hogy kernel resz legyen nyilt, es userspace resz meg nem feltetlen.
A kernel resz ugysem a nagy super technlogias resze a dolognak, nem igazan van bene olyan dolog. nouveau -sok, mar reg tudnak mindent :)

(A kerdeses hivas, egyebkent nem biztos, hogy tenyleg abba a ketegiraba esik amit GPL flaggel szokas ellatni..)

"The idea behind GPL-only symbols is that they are so deeply internal to the kernel that any module using them can only be a derived product of the kernel"

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Megfelelő kommunikációval megoldható lenne, hogy a gyártó időben értesüljön a kernel api változásokról. Ha azon felül lép fel probléma, az a gyártó felelőssége.

Értem én, hogy jobb lenne ha kernel kontrollálná a helyzetet, de ezt nem fogják tudni kierőszakolni.

A szaralinuksz mert szar a driver sztereotípiáktól meg így sem szabadulnak. Miért ne dobhatnák le a vállukról legalább a tényleges felelősséget?

"a gyártó időben értesüljön a kernel api változásokról."

Most viccelsz, meg a userek se mindig ertesulnek rola. Egyaltalan az api valtozas olyan dolog a kernelben, minthogy patchelgetik - napi szintu dolog. Igy nehez is ra fejleszteni. Eleg csak a vmware drivert megnezni, meg a vele valo szopasokat - pedig ott aztan a kernel oldali resz nyiltabb mar nem is lehetne.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

-rc2 utan +6 het a varhato mire distroba kerul.
Enyi ideje van a gyartonak, ha senki nem szolt neki, es meg deprecatednek sem volt jelolve, es nem olvas lkml -t.

pl. kb. 3 kiadasonkent kell egy trivilis change az NVIDIA driverbe. Nem olyan sok.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

"es nem olvas lkml-t"
Na ez a fail. Szerinted ki fog egy rohadt api change-ert levlistakat nyalazni? Kellene egy olyan ertesito felulet, ahova be lehet regelni, hogy ez a fuggveny, eddig ez volt a szignatura, most meg emez, rakattintva a side effectek listaja. Es annak mar ertelme is lenne. Ez igy semmi.

Az a baj, hogy a mostani fejlesztesi modell egy sokkal kisebb kodnal sem mindig ertelmes, ekkoranal mar vegkepp nem az.

Azt mar nem is akarom pengetni, hogy nincs hivatalos API doksi se nagyon.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Szerintem aki nem erdekelt kernel modul fejlesztesben az nem fog lkml olvasgatni.
Van CI rendszer, minden komoly helyen, hogy jelezze bajt olvasas nelkul...

rc2 meg van evente 4-5 szor mondjuk, a CI hasznalni nem kepes amator kis cegeknek ilyenkor erdemes tesztelni, ha releasrekor nem akarnak meglepetest.

Meg kesz szerncse, hogy nem dugjak el forrast ket release kozott :)

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Nem a CI-vel van a baj. Az csak azt tudja jelezni, hogy he, sracok itt valami nemokes. De azt mar pl. nem fogja megmondani neked, hogy a helyett az API hivas helyett, ami most nem fordul, mi van. Azt egy tisztesseges doksi tudna csak megmondani.

Es itt elsosorban nem az LKML olvasasaval vagy nem olvasasaval van a baj. Hanem, ha pl. az Oracle is mostantol csak valami levelezolistan/blogon mondogatna, hogy milyen API hivasok kerulnek ki a Java SE-bol, hat a fel vilag felhordulne, hogy de ezt megis hogy. De a Linux kerneltol ez valamiert el van turve.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

"De azt mar pl. nem fogja megmondani neked, hogy a helyett az API hivas helyett, ami most nem fordul, mi van. Azt egy tisztesseges doksi tudna csak megmondani."

Szerintem erre a commit üzenetek simán alkalmasak.

"Hanem, ha pl. az Oracle is mostantol csak valami levelezolistan/blogon mondogatna, hogy milyen API hivasok kerulnek ki a Java SE-bol, hat a fel vilag felhordulne, hogy de ezt megis hogy. De a Linux kerneltol ez valamiert el van turve."

Alma-körte. A Java public API-jához inkább a kernel-user space API hasonlítható. Azért meg Java körökben se szokás anyázni, ha egy java.lang. osztály egyik-másik privát metódusa eltűnik vagy megváltozik.

"commit uzenetek"

A Javahoz senki nem akar drivereket irni, a kernelhez igen. Szoval lehet, hogy alma-korte, de azert van nemi koze egymashoz.

Egyebkent meg a kernelben nincs public api, pont ez a problema. Nem csak a userspace-ba exportalt feluletet kellene karbantartani, hanem a driverek altal hasznaltat is. Csakhat persze az az evolucios fejelsztesbe mar nem fer bele.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Drivereket talán nem, de esetleg a JVM mélyén turkálni igen. Persze a vonatkozó licenc tiszteletben tartása mellett.

Mindenkinek adott a lehetőség, hogy hozzáadja a kernelhez a maga driverét, és onnantól már a nem az ő gondja a változások lekövetése. Ha ilyen-olyan okok miatt nem teszi, lelke rajta.

A nem GPL(-kompatibilis) drivereken viszont egy stabil driver API se segítene, mert jogilag úgyse használhatnák.

Korábbi tapasztalataim miatt inkább messzire kerülöm.

Szerintem Linusnak igaza van abban, hogyha nem ezt a licencet választja, és nem tartottak volna ki mellette, akkor egyáltalán nem jutottunk volna idáig. Viszont hallottam már olyan mendemondákat, hogy állítólag van olyan oprendszer, ami más licencű, és az nvidia driver is elég jól működik rajta...

Lehet hogy igaza van. Akkor viszont fogadjuk el, hogy Desktop linuxot használni merő hóbort. Unaloműzés.
Ma már böngészni sem lehet rendes VGA driver nélkül. Persze jól elvan az ember framebufferen is... :)

Szerk:

Viszont visszatérve a valóságba, szerinted melyik alternatívában érdemes hinni? Egy olyanban ami azt jósolja hogy a Linux desktop hősként fog elbukni abban a harcban, hogy a világot nyílt forrásúvá tegye? Vagy abban hogy valódi alternatívát fog jelenteni? Ki-ki döntse el maga.

Szerk:

Amúgy ha belegondolsz, egy csomó nem GPL userspace program van linux-ra. Az nem baj? Nem tartana-e esetleg a linux még előrébb, ha azt is megtiltják? Csak a drivereknél kell a mártírt játszani? Ez valóban ideológiai kérdés?

En nem tudom, hogy igaza van-e Linusnak vagy sem, nem latom ilyen komplexen a vilagot. En csak azt latom, hogy ha nem Intel VGA-d van, akkor a pokol tornacaibol hatot biztos meg kell jarnod ahhoz, hogy valami normalis rendszered legyen.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Ja mert Windows kernel fo verzio szam valtozaskor nem tobb hetes/honapos munka szokott lenni a driver at/ujra irasa, ha egyeltalan kiadjak a drivert.

Mar 1 full time Linux Driver fejlesztonel 1% alatti koltseg, az<sarcarsm>t a rendkivul sok es bonyolult</sarcarsm> API valtozast kovetni.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Szamolj legyszives utana hogy hany nap telik el egy Windows kernel verziovaltas es egy Linux kernel verzio valtas kozott. Tedd ki a megfelelo relaciojeleket.

Es ugye Linux eseteben nincs fo verzioszam valtas. Ott minden egyes verziovaltas API valtast indikal.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Probald mar meg hasznalni az egergorgot, es nezd mar meg, hogy mirol szol a szal. Totalisan erdektelen, milyen disztron nem mukodik egyutt az nVidia driver meg a kernel. Ez ilyen inter-disztro problema.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Ezt találtam, az egérgörgő segítségével: "Szamolj legyszives utana hogy hany nap telik el [...] Linux kernel verzio valtas kozott."

Értem én, hogy "kernel verzió váltás", csak az maradt ki, hogy melyik környezetben. A kernel.org szerveren? Érdektelen. Kedvenc disztródon? Úgy egy kicsit több nap jön ki, nem?

A sztori arrol szol, hogy az nVidia driver es a kernel kozott folyamatos feszultsegek vannak, mert az nVidia driver nem GPL-es, igy a kernelben nem mindenhez van hozzaferese. Ez problemakat jelent egyreszt az nVidia driverk kompatibilisse teteleben. Ebbol alakult ki a beszelgetes soran az, hogy az zart drivereknek ez csak az egyik problemajuk, a masik a folyamatosan valtozo API.
Ez utobbi ugye foleg azert problema, mert a zart driverek igyekeznek - hacsak lehet - tobb disztroval - pontosabban tobb kernelverzioval - is kompatibilisek lenni (innentol ertelmetlen a disztro feszegetese). Mivel a driverek nem hibatlan szoftverek, ezert van, hogy a vendor csak egy kesobbi driverben fixal dolgokat - viszont esetleg nem teszi minden kernelverzioval visszafele kompatibilisse, akar azert, mert azota tul sok ido telt el, es a driver szerkezete mar nem teszi ezt lehetove; akar azert, mert tul nagy effort (= draga) lenne.

Aztan itt kezdodott a Windows es a Linux API valtozasok osszehasonlitgatasa, ebbol jott ki ez a szal, itt tartunk most.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

"Szamolj legyszives utana hogy hany nap telik el ..."

Az nvidia kártyám tehát jó ideig biztosan üzemképes marad. Még az sincs kizárva, hogy évekre. Közben meg bármi történhet. Az nvidia változtathat a hozzáállásán; átvonulhat másik piacra mint a Matrox; stb. Ha bevételt remélnek tőlem, akkor azért meg kell dolgozni. Ha meg nem akarnak, ...

Nem lehet hogy téged igazából az zavar meg, hogy belátsz a fejlesztők hátsó udvarába? Hogy nem ér utólagos meglepetésként, hogy a vadi új OS már nem támogatja a kedvenc hardveredet, hanem hónapokkal/évekkel előre vetítődik a lehetősége?

Az nVidia kb. 5 evig tamogat egy hardvert a normal driver bleeding edge verzioval. Regebbi hardvarek kikerulhetnek a bleeding edge releasbol, es a meg eletben levo 2 maintance modban levo fo verzioju driver egyike tamogathatja.
Max. 15 ev szerintem. Utana csak nouveau.

A kernel reszrol nem problemas a tovabbi tamogatasuk, soha sem azzal volt a baj. A nagyobb xorg valtozasok sokkal nehezebb kovetni.
Tehet valoszinuleg kernelt upgradelhetsz, par soros patchet lehet be kell majd szerezned driverhez.
Egy Xorg fo verzional valoszinuleg meg kell majd maradnod.
nouveau koveti az xorgot is es nem kell egy regi binaris xorg driverre tamaszkodnod.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

5.x 6.x ugras rendesen tacsra vagott sok drivert, nehez megmondani menyi ido volt kovetni es menyire csak #@%$ raja a gyartok.

Ha mar Nvidianal vagyunk, evente kb. 10+ driver verziot add ki Windowsra (Gyakrabban mint ahogy Linux kernelt adnak ki!! ), fuggetlenul attol, hogy volt -e OS release.
Egy idoben kb. 5 Windows family -t kell tamogatnia, kb. evente 5 verziohoz WHQL cert is szerez.
5*5*250$ (ha egyszerre kered 32 ill. 64 bitre nem kell pluszban fizetni archonkent, nem szamoljuk az at nem meneseket) + 173$/Ev alairo cert a Verisign-tol. Az 6423$ also hangon es meg fejlesztonek nem is fizettek.

Ez maris egy fejleszo eves koltsegenek 3%-a felett van.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Igen, az XP->Vista valtas nagy volt, ezt mindenki elismeri. Ezzel egy akkor _5_ eves oprendszert valtottak, mar ne haragudj. Ez az operacios rendszer ma 11 eves. Hany Linux kernel is jelent meg az elmult 11 evben?

Havonta ad ki drivert dologhoz meg annyit, hogy a GPU-nal picit mas a helyzet, mint mondjuk egy random mas eszkoznel. GPU-nal egyreszt benne van az is, hogy kemenyen utanaigazitjak a jatekoknak. Egy hangkartya driver vagy egy halokartya driver eseten gyanitom nincs ekkora rohanas. Az a 6K USD miatt meg nehogy megsajnaljam az nVidia-t.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Mar az X-FI is opensource driver, nem tudok kernelen kivuli hang kartyarol. Ugyhogy nem erdekes.

Amirol tudok, hogy sok van kernelen kivul, az specialis meroeszkozok. Leginkabb RHEL alapu ScientificLinux alatt, hasznaljak oket (meg ISA-s kartyakat is hasznalnak manapssag)...

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

A Linux 20 éves. Az Xorg 8 éves. Hány év kell még nekik, hogy valóban használható legyen desktopra?
"amíg a Wayland használható nem lesz"
Az OS X-ben a Quartznak hány év fejlesztés kellett, míg használható lett? Az OS X első verziója, 1999-ben (desktop: 2001) már olyan Quartzot tartalmazott, ami használható volt, a többi OS kb. 4-5 évvel utána követte.

Sokan mondják, hogy "hát, a Linuxot komoly helyeken használják, szuperszámítógépeken, X, Y és Z helyeken"
Ez baromira irreleváns. Egy szuperszámítógép szoftverét nem szokták updatelni, főleg nem security miatt, mivel nem ül az interneten. Egy interneten ülő szerver pedig nem desktop gép.
Jelenleg desktopra használhatatlan a Linux tömegesen. Pártízezer embernek lehet, hogy gond nélkül megy, de párszázmillióról kéne beszélni, hogy valóban ki lehessen mutatni normális méretű (nem statisztikai hibahatáron belül lévő) részesedést a desktop piacon.
Amúgy aki HPC-re használja, afelé egy kérdés: a normális OpenCL/CUDA/ATI Stream támogatást Linux alatt mennyire érinti a kernel folyamatos változása?

Amúgy ez a fajta fejlesztési modell tökéletesen jó addig, amíg egy kísérleti-kutatási projektről van szó, hiszen egy kutatás, kísérlet pont arról szól, hogy gyorsan prototipizálva, a nem működő megoldásokat tesztelve kiderülne, mi az, ami élesben működik. Csakhogy ha a Linux komolynak akarja gondolni magát, akkor ne kísérleti-kutatási projekt legyen, amit a felhasználók tesztelnek élesben. Mert jelenleg még mindig ugyanaz a fejlesztési modell megy, mint 15 éve, viszont akkor senki ne is várja, hogy a felhasználói bázis a 15 évvel ezelőttihez képest jelentősen meg fog változni (lásd Ubuntu #1 bug megoldása mint cél).

A Linux egy olyan kísérleti rendszer, amit szakértők készítenek elsősorban szakértőknek. Nem desktop rendszer.

Meg kéne érteni, hogy komoly rendszer bazár fejlesztéssel nem tud működni egy bizonyos szint után. Persze a kutatás-kísérletezés esetén a bazár modell nagyon is jó, de ott meg is reked.

Kint van a Wayland 1.0, az Ubuntu wiki szerint amint kész lesz, ráharapnak, nem hiszem hogy 2 évnél több kellene.

Pontosan a tudományos háttér miatt mondom, hogy várjunk még egy kicsit. ~10 évvel ezelőtt a desktop linux mögött nem állt cég. A RH se a desktop vonalat nyomta sose, maga a desktop linux csak úgy random fejlődött, mondhatni kontroll nélkül. A Windows / OS X azért tart itt, mert ipari érdekeltség van mögöttük. A Linux desktop mögött ilyen még sose volt.

Pár éve itt van Mark és az Ubuntu és ahogy látom komolyan gondolják a dolgot (megjött az érdekeltség). Az eddigi bazár mellett miért ne tolhatnák a szekeret a stabilitás irányába? Egy LTS 5 évig támogatott és minden 2. évben jön ki egy új verzió. A stabil drivereket simán lehetne egy kétéves ciklushoz igazítani, az meg hogy kéthavonta vagy félévente kiadnak-e új változatot, az már az ő dolguk.

" ~10 évvel ezelőtt a desktop linux mögött nem állt cég."
Na nezzuk.
SuSe GmbH 1992 ota van, 2003-ban vasarolta fel a Novell. Majdnem 10 eve mar tulajdonost is valtott az egyik olyan ceg, ami desktop Linux eladasbol (megoldasszallitokent) elt.
Ubuntu es mogotte a Canonical 8 eve van.
"maga a desktop linux csak úgy random fejlődött, mondhatni kontroll nélkül."
Ez ez ma is igy van. Van Xorg, Wayland, Plymouth, systemv, PolicyKit meg ezerfele egymassal konkuralo megoldas ugyanarra a problemara, freedesktop.org ajanlasok, amit vagy betartanak vagynem. Linux Standard Base, amit vagy betartanak, vagy nem. POSIX, amit vagy betartanak, vagy nem. Linux Filesystem Hierarchy Standard, amit vagy betartanak, vagy nem. Mondom, ez egy kiserleti-kutatasi rendszer, semmi koze az enterprise-grade meg user friendly szavakhoz.

"A Windows / OS X azért tart itt, mert ipari érdekeltség van mögöttük. A Linux desktop mögött ilyen még sose volt."
Ez az igazi kettos merce. Most akkor megint az van, hogy a Linux amator dolog, nincs mogotte ipar. Amikor meg arrol van szo, hog a Linux milyen jo, akkor meg az van, hogy hat sok szervert ezzel uzemeltetnek, vehetsz supportot, szuperszamitogepeken is ez fut. Csak egy dolgot mondok: a sok otthoni, Linuxot hasznalo SOHO NAT-doboz, a sok Linuxos set-top box nem ipari erdek? Ne viccelj.

Ertsd meg: a Windows es az OS X azert tart itt, mert kozpontositott, adott elvek szerint felepulo TERVEK alapjan keszitik. Van tervuk arra, hogy X,Y vagy Z release-ben mit fognak megvalositani, jo par evre elore. Vegeznek kozben persze kutatasokat, hogy mit es hogyan lehetne csinalni (lasd Microsoft Research Singularity OS), de a kutatasok soha nem eles dolgok, maximum tanulnak belole.

"Na nezzuk." - Jogos

"Linuxot hasznalo SOHO NAT-doboz, a sok Linuxos set-top box nem ipari erdek?"

Hogyne lenne az, csak nem desktop vonalon. Teljesen megértem amit írsz. De ilyenkor felmerül bennem a kérdés, hogy a SuSe miért nem tervezett? Vagy a többiek? Miért nem mutatott valaki egy egységes fejlesztési irányt, amit a magukra valamit is adó fejlesztők betartanak? Miért hagyták, hogy ez a platform így fregmentálódjon? Miért nem lehetett meghagyni a rendszer tudományos - fantasztikus ágát és mellé építeni egy stabilat, ami ciklusonként áthúzza a jó dolgokat (mint most az RH teszi)?

Most a Canonical próbál egy egységes irányba húzni (Unity, Ubuntu SDK), egyféle fsck próbál lenni egy megzakkant ext4-en. Lesz amit elront és lesz amit helyrehoz.

Újra: teljesen jogos amit írsz, azonban az észérvek ellenére hiszek a desktop linux jövőjében. Talán ezt hívják (indokolatlan?) optimizmusnak.

" a SuSe miért nem tervezett"
A SuSE is csinalt rengeteg sajat rendszert, a legnevezetesebb a YaST/YaST2 grafikus es ncurses valtozata.

"Most a Canonical próbál egy egységes irányba húzni (Unity, Ubuntu SDK)"
Marmint arra az egyseges iranyra gondolsz, amit csak ok fognak hasznalni?
Igen, azt lehet mondani, hogy az egy operacios rendszer lesz, Ubuntu, de hogy semmi massal nem lesz kompatiblis, ugyanugy mint a Windows es OS X, az is biztos. Nincs ezzel gond, csak akkor nekik kene a teljes stack fejleszteset atvenni. Glibc, Xorg, kernel, minden.

Tudod, amig nem te felelsz a teljes, core businessedbe (ami az Ubuntu eseten operacios rendszer keszites) tartozo folyamatok minosegellenorzeseert, es nincs is befolyasod arra, hogy a kulonfele komponensek adott hataridore mit es hogyan keszitenek el (milyen lesz a kernel, eppen mit tud az Xorg, eppen mit tud a Glibc), es a te idodet 99%-ban az viszi el, hogy a kulonfele eltero verziok kozotti hegeszteseket csinalod, ugy baromira nehez innovalni, meg rendszert epiteni.

Erted, Java eseten tudjuk, hogy ami 12 eve mukodo API volt, az most is az, nem kell vele torodni. Van egy jol bevalt megoldasod loggingra ami core Java API-t hasznal? Hasznalhatod 5 ev mulva is.
Ilyen a Linux vilagban nincs. Van egy jol bevalt scripted, ami hal API-t hasznal? 2 ev mulva dobhatod ki, irhatod ujra.
Ezt ertem en az alatt, hogy terveznek-e vagy nem es ha igen, milyen mertekben.
Hanyszor irtak ujra a startup scripteket? Volt init, upstart, most lesz systemd vagy valami mas 2 ev mulva stb.
A rendes mernokok "legoznak". Viszont ez a fajta viselkedes, ami a Linux korul folyik, olyan, mint amikor vennel egy uj Lego keszletet, es annak a pockei mar nem passzolnanak a te meglevo kockaidhoz, es azon kene dolgoznod, hogy valahogyan osszeilleszd oket. Ez is munka, idobe es penzbe telik, csak nem visz sokkal elorebb.

"Miért hagyták, hogy ez a platform így fregmentálódjon?"
Miert, van aki osszefogna? Nincs. Mindenki szabadon mehet az elkepzelesei utan, senki nem mondja meg neki, hogy "acsi, feleslegesen szorod el az idodet erre, mas mar kitalalt jobbat."

"ami ciklusonként áthúzza a jó dolgokat (mint most az RH teszi)?"
Az RH sem ezt teszi. O is epiti a sajat rendszeret, mint a Canonical (gondolok a plymouthra, a sok kulonfele, Fedoraban megjeleno ujitasra).
Nincs olyan, hogy "en vagyok a GNU/Linux operacios rendszer fejlesztoje, es amit csinalok, ha jo, akkor bekerul a GNU/Linux rendszerbe"
Azert nincs, mert nincs olyan, hogy A GNU/Linux operacios rendszer.
A kulonfele disztroepitok azt tesznek bele egy rendszerbe, ami nekik tetszik.
Mondjuk Linus csinalhatna egy olyat, hogy copyrightolja a Linux nevet, es csak azon disztroepitok szamara engedelyezi a hasznalatat, akik bizonyos konvenciokat (LFHS, LSB es meg ilyenek) betartanak, mas nem nevezheti a rendszeret Linux disztribucionak.
De ez ugye a nagyon szabad FLOSS kozossegbe nem fer bele.
Pedig itt egy operacios rendszerrol van szo, ami nagyon is mernoki munka. Itt nem nagyon van helye a muveszi szabadsagnak :)

"Megfelelő kommunikációval megoldható lenne, hogy a gyártó időben értesüljön a kernel api változásokról. Ha azon felül lép fel probléma, az a gyártó felelőssége."

Mi a fenerol beszelsz ?
Ha azt akarod bemagyarazni, hogy azert crash leader az NVIDIA driver, mert valmit masut lecsereltek, akkor felre vay
gy informalva.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Például ha el akarnám dönteni, hogy vegyek-e nvidia kártyát elég nagy bajban lennék(vagyok is). Mindenki /kártya/kiadás/gyári/nem gyári más tapasztalatokról számol be. Nem látok szisztematikusan behatárolható problémákat.

Szerk:

Nyilván nem csak az a baj, hogy változik az api, hanem az is hogy maga a driver elég rugalmatlan, sok módosítást kell csinálni egy változtatáskor benne, és emiatt néhol el is felejtik. Ezért szoktam mondani, hogy a driver rugalmassági rétege legyen nyílt, a többi lehet zárt.

Nem kell sokat.
Keres ra API changekere. En mar szoptam azzal, hogy regi drivert uj kornyezetbe teni. Ami nekem akkor 1 nap volt, annak aki kepben van kevesebb mint 1 ora.
Aki karban tartja drivert annak 2-3 havonta 1 ora bele kell, hogy ferjen, ha erdekli a nem enterprise kiadas is. Ha csak az enterprise akkor kb. 3 evente van 1 nap moka.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Elszor is erdemes bugzillan jelenteni, hogy masok is segithessenek.

Milyen verzioknal jelentkezik ?
Melyik distrot melyik kernelel hasznalod ?
Milyen gyakori ill. milyen hoszu az "akadozas", milyen feltetelek mellett all elo a hiba? Hatasal van -e halozati komunikaciora (ping latency /lost) ?
Honnan jott az otlet, hogy azokat bitket tiltsd le ? Es pontosan melyiket kell tiltanod

Most kezeim alatt van :
00:02.0 VGA compatible controller [0300]: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor Graphics Controller [8086:0162] (rev 09)
Linux hostname 3.5.4-gentoo #1 SMP PREEMPT Wed Oct 3 01:24:50 CEST 2012 x86_64 Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz GenuineIntel GNU/Linux

1 monitor DVI -on, egy meg HDMI -n (+ hang).

Ill. egy [8086:0154] rev 09 Notebook, 3.5.5-2.fc17.x86_64, notebook.

Nem tapasztalok semmi ilyesmit, ha tudom reprodukalni segitek levadaszni.

(Lehet tudok meg eroforrast szerezni)

Latencytop ill. talan az oprofile lehet kellesz majd, (talan perf ill. systemtap is..)

cat /proc/interrupts szerint milyen utemben no az IRQ szam normal ill. akadozasos esetben ?

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Ez hosszú lesz.
Adatok:
00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07)
(a specifikáció: Intel® Pentium Dual Core™ T4500 / 2GB / 320GB / Intel® Graphics Media Accelerator (GMA) 4500M)
Jelenleg:
Linux hostname 3.2.0-32-generic #51-Ubuntu SMP Wed Sep 26 21:33:09 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
Ubuntu 12.04.1 LTS
Amúgy a driver elég jó teljesítményt hoz ki a gépből, "csak" ez az egy gond van vele.

Történet:
Lucid volt az első rendszer amit látott a gép.(freedos után)
Ott még elég látványosan pörgette az udev-et. Az udev monitorral meg is lehetett figyelni, a folyamatos eseményeket, amelyek egyértelműen X-el voltak kapcsolatosak.
Aztán próbaképp áttértem a 3.0-ás kernelre. Ott a kworker pörgött ugyan úgy. Ekkor találtam erre az oldalra:
https://bugzilla.redhat.com/show_bug.cgi?id=528312
Itt azt a patch-et aminek származékát a mai napig sikeresen használom:
https://bugzilla.redhat.com/attachment.cgi?id=423471
Persze már nem szórakozom kernel paraméterekkel, az újabb verziók meg patch-elésénél. 0x38000000 is the magic number.
Maradtam a 3.0-ás kernelnél hosszú ideig. Aztán jött a memória bővítés és a pae kernel(vissza a 2.6-os sorozatba). Ott már nem kellett patch-elnem, mert nem jelentkezett a hiba. Felteszem a 2.6-os sorozatban időközben javult, vagy elfedődött.
Aztán jött a nagy ugrás lucid-ról precise-re. Itt a hiba visszatért, de rövid időre jelentkezik, így nehéz elcsípni.
Rájöttem hogy kell DKMS-el lefordítani a drivert:
http://hup.hu/node/114846
így már nem kell minden kernel relase-nél külön patch-elnem.
Áttértem 64 bitre:
http://hup.hu/node/117383
Semmi változás.

powertop:
Ez az eszköz egyértelműen kimutatja hogy a hiba jelentkezésekor növekszik az i915 megszakítások száma.
https://bbs.archlinux.org/viewtopic.php?pid=860659#p860659

Tünetek:
A legnagyobb baj az hogy még azt sem sikerült meghatározni hogy mi váltja ki a jelenséget. Lucid alatt elég látványos volt, hosszú percekig tartott. Precise alatt ez már akár néhány másodperc alatt is kifújhat. A boot után jelentkezik, random idő után, és szintén random idő után abbahagyja. Pl. Lucid alatt Virtualbox XP futtatása egyértelműen kiprovokálta.

A jelenséget egyértelműen az egérkurzor késleltető mozgása jelzi. Hálózati teszteket nem végeztem. :)

Perspektívák:
Feltűnt hogy boot-kor az ubuntu dektop ezt a jockey nevű programot futtatja, ez például gyanús nekem, hogy esetleg kiprovokálhatja. Nem teszteltem.

Ha további dolgokat kell tesztelni, eltávolítom a DKMS modult, de csak indokolt esetben, mert közben használják ezt a gépet.

Szóval szerintem dolgozd fel az információkat. Aztán jelezd hogy mit mérjek le. Azt jó lenne például kideríteni, hogy pontosan mi a megszakítás hotplug kódja, ami ezt okozza.

Gondolom firmware frissites megvolt.

lspci -nn ami kiirja a product id -t, nehogy rosz chip manualjat ill. errate -jet olvassam.

Konnyen lehet, hogy egy elfeljetett pull down resistor (vagy hasonlo blodseg) a hiba okozoja.

Mi a Notebook tipus szama ill. gyartoja ? Biztosit -e notebook vendor VGA drivert, ami nem az Inteltol szarmazik ?
Mas rendszeren probaltad -e engedelyezett hotpluggal ?

Bele tudsz -e nezni notebookba ?

0x08000000 -el probaltad -e ? (hex(1<<27),HDMID_HOTPLUG_INT_EN ) A patchben emlitettek. Az i915_reg.h -bol lehet megnezni melyik bit az.

xrandr velhetoleg kilistazza a portokat amirol a driver tud, van -e olyan koztuk ami fizikailag nem is letezik ? (Jo lenne majd eldonteni, hogy letezo ojjektum kuldi -e)

A referalt kodsor csak az engedelyezesre vonatkozik initkor, a irq event masutt jon be:

Kb. itt teheti worker szalra, es logolja statuszt.
http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=blo…

* drm_driver level can be used in the specific drm driver. It is used
* to add the debug info related with the drm driver. For example:
* i915_drv, i915_dma, i915_gem, radeon_drv,
* The macro definition of DRM_DEBUG_DRIVER can be used.
* DRM_DEBUG_DRIVER(fmt, args...)
* The debug info by using the DRM_DEBUG_DRIVER can be obtained by
* adding the boot option of "drm.debug=0x02"

Ha igy bootolsz velhetoleg kiirja hotplug statuszt, a kernel logra (dmesg).

(Gondolom neked is IR-PCI-MSI-edge van i915 hoz irva az interruptsban)

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Köszi.
Ezekkel a tippekkel biztos kijutok majd a holtpontról.
Arra reagálok amire most tudok, a többire majd később.

"Gondolom firmware frissites megvolt."
Ilyesmire gondolsz?
https://launchpad.net/~sarvatt/+archive/next?field.series_filter=precise
Tegyem fel?

"Mi a Notebook tipus szama ill. gyartoja ?"
CQ56 Presario

"Bele tudsz -e nezni notebookba ?"
Ha szükséges, bár remélem odáig nem fajul a dolog. :)

"Ha igy bootolsz velhetoleg kiirja hotplug statuszt, a kernel logra (dmesg)."

Szuper. Ez előre visz majd.

Rossz linket adtam.
Ez a típusa:
http://h10025.www1.hp.com/ewfrf/wc/softwareCategory?os=4063&lc=hu&cc=hu…

És a segédprogramoknál tényleg ott van:
HP BIOS frissítés UEFI ►

Szerk:
http://h30434.www3.hp.com/t5/Other-Notebook-PC-Questions/How-to-use-the…

Ez alapján próbáltam haladni, de annál a lépésnél hogy:
" Download and run the HP Notebook System BIOS Update from the HP support drivers page, since the usb drive is labeled correctly it will install the bios update to the USB drive."
nem veszi figyelembe hogy "labeled correctly" és hibaüzenettel tér vissza, hogy a driverét nem tudja betölteni. Szerintem nagyon nem a "labeled correctly" USB-re akar írni hanem BIOS-t akar frissíteni.

Jól értem hogy az által hogy az USB drive HP_TOOLS partícióján a :\Hewlett-Packard\BIOSUpdate felkerült, ennek meg kéne jelennie valahol az UEFI menüjében?

Hogy egy klasszikust idézzek:
Fuck you HP! :)

Már csak az a kérdés mikor szánom rá magam hogy a Win7-nek particionáljak, GRUB-ot újra rakjak(és még egy DVD-t is fel kell áldoznom a szent ügy érdekében)... Freedos-al adják a gépet, de csak Win7-en lehet bios-t frissíteni. Ez kb. olyan logikus mint a CD meghajtó telepítő CD. :)
Pláne ha kiderül hogy a 15-ös BIOS már tudja ezeket.

"Gondolom firmware frissites megvolt."

Megvan. Particionálás, win7 telepítés, a tapasztalat hogy 32 bites LiveCD-vel nem lehet 64-bites grub-ot újratenni, win7 frissítés hogy nyugodjon már le, majd végül a bios frissítés.

Egész nap amíg babráltam a win7-el, a proci ventilátor végig porszívó fokozaton volt. Amint felraktam a bios frissítést hihetetlen csend lett. Még a memória fogyasztás is pár 100 Mb-al kevesebb lett alapjáraton.(Előtte akkora kurva nagy memory leak-et csinált valami Windows Update közben, hogy csak úgy néztem a Resource Monitor-ban hogy pörögnek a GB-ok felfelé memória foglalásban)

Ubuntu alatt kiszedtem a buherált drivert, és most békésen várom hogy jöjjön a hiba, egyelőre nem jött. Biztató.

Még egy kis melléklet: 


$ xrandr 
Screen 0: minimum 320 x 200, current 1366 x 768, maximum 8192 x 8192
LVDS1 connected 1366x768+0+0 (normal left inverted right x axis y axis) 344mm x 194mm
   1366x768       59.6*+
   1360x768       59.8     60.0  
   1024x768       60.0  
   800x600        60.3     56.2  
   640x480        59.9  
VGA1 disconnected (normal left inverted right x axis y axis)
HDMI1 disconnected (normal left inverted right x axis y axis)
DP1 disconnected (normal left inverted right x axis y axis)
DP2 disconnected (normal left inverted right x axis y axis)

Szerk:

Oké, ennyi idő után szerintem nyugodtan kijelenthetem: Probléma megoldva. Köszönöm szépen a segítséget, és sajnálom hogy néha hülyeségeket beszélek. Tényleg nem vagyok túl járatos bizonyos területeken. Pl. magamtól eszembe nem jutott volna hogy a firmware okozhatja a hibát.

Ezen kívül az USB kezeléssel is voltak komoly gondok, amíg a régi BIOS volt. Remélem most az is jobb lesz.

Így oké, engem az zavart meg, hogy volt itt "linux desktop éve", meg "nem fog menni Linuxon", meg hasonlók. Ilyet általában akkor írnak ide, amikor azt akarják kifejezni, hogy használj windowst.
Akkor lényegében az a helyzet, hogy a kernelben elérhető lett egy funkció, amit a zárt driverek nem használhatnak, azaz minden marad a régiben?

--
Debian - The "What?!" starts not!
http://nyizsa.blogspot.com

Jól értem, most meg nem érek fel azokhoz, akik a "linux-al foglalkoznak", pl cox. :) Hát akkor ez nagyon le lesújtó vélemény.

Ja, elolvashattam volna az Nvidia Optimus cikket pl a wikipédián, de bevallom őszintén, annyira nem érdekel a téma, nem akartam beleásni magam. Hogy miért kezdtem ezt a szálat? Na, ez tényleg hiba volt. Belekarattyolni valamibe aminek még utánaolvasni is lusta vagyok. Tipikus hupper hiba. Bocsi mester. Amúgy lehet sokaknak jól jött hogy nem kell utánaolvasniuk.

Annyi lehet a mentségemre(igaz nem sok), hogy tulajdonképpen eredetileg nem én kezdtem el tudatlanul belekotyogni, csak reagáltam rá.

Amúgy biztos ez zavar téged? Amit fenn műveltem, hogy a firmware-ből nem rögtön a BIOS-ra gondoltam, az szerintem sokkal cikibb.

Én az lkml-ről trollkodtam, az NVIDIA kártyáról csak nyilvánvaló dologban tévedtem, de annak semmi köze nem volt a trollkodáshoz.
Mondok egy példát: Attól hogy te egy troll vagy, még érthetsz ahhoz amit csinálsz.
Szerintem a trollkodáshoz nem elég tévedni, az is kell hozzá, hogy ne ismerd el a tévedésed. Mondj példát ilyenre.

Még...Még...Kínozz!

Nem! Amit te vergődésnek látsz az valójában tárgyilagosság. Amúgy egy troll vitában ez kétirányú dolog. Mind a két fél úgy gondolja magáról hogy ő a tárgyilagos, a másik fél meg vergődik.

De hogy valami konkrétumot is mondjak, mert ugye az a lényeg egy normális vitában:
Szerintem az a szemléletmódbeli különbség kettőnk között, hogy te többet vársz el másoktól mint én. Én teljesen konzisztens vagyok önmagammal, hiszen ha én írtam volna ezt a cikket, biztos adok valami kivonatot a körülményekről, úgy ahogy trey is szokta. Érdekes módon az ő cikkeit különösebb utánajárás nélkül meg szoktam érteni. Ha meg a részletekre is kíváncsi vagyok, külön utánaolvasok nyilván. Azt persze nem tudtam, honnan is tudhattam volna, hogy nálad ez elvárás. De nem baj ez, nem vagyunk egyformák. Hidd el, legközelebb kétszer is meggondolom, hogy a cikkeidhez hozzászóljak.
Mindenesetre elég flame gyanús, hogy ahol lehet mellőzöd a részleteket, elvárod hogy más találja ki a problémádat, ugyanakkor még fel is háborodsz, undorító vérgőzös stílusban, ha olyanok szólnak hozzá a témához, akiket közvetlenül nem érint a dolog, így lehet hogy más véleményen lennének mint te.

Valóban, ez szerintem is így van. Viszont van olyan is, hogy az ember tévesen méri fel, hogy mi a fontos és mi nem. Lehet ebben tévedtem. Ezért szoktam részben a fórumozók véleményére hagyatkozni, mert nekik ebben több tapasztalata lehet. Azt még mindig nem értem, hogy az Optimus kártya, mint konkrét eset, mit változtatna a véleményemen, amely úgy általában a kernel fejlesztésre vonatkozott, többnyire. De ez biztos a tudatlanságom miatt van.

Továbbá azt sem értem most mivel érdemeltem ki ezt az emberi hangnemet tőled? így jutott erőm a problémára fókuszálni, így felvetődött bennem, hogy esetleg lehet valami abban amit mondasz. Hogy várhatod valakitől hogy fontolóra vegye a véleményedet? Hajszál pontosan úgy viselkedsz mint egy troll. Most megleptél ezzel a tárgyilagos hozzászólással.

nem kegyvesztett, siman szar. azt hittem egyszer a C#-rol, hogy legalabb nyelvi elemekben fejlett, de rajottem, hogy csak ontokonbokes az egesz (foleg a vesszoparika - a type reitifacion meglete ill hianya a respektiv nyelvekben), innentol kar az idomet pazarolni veluk ;)

es remelem ez is megvolt

"Viszont van olyan is, hogy az ember tévesen méri fel, hogy mi a fontos és mi nem. Lehet ebben tévedtem. Ezért szoktam részben a fórumozók véleményére hagyatkozni, mert nekik ebben több tapasztalata lehet."

Azt azért illik hozzátennem, hogy ez a hozzáállás főleg az angol tudásomnak köszönhető, nem annak hogy eredendően bűnös lélek vagyok. Olyan, hogy a számomra lényegesnek tűnő dolgokat kiemelem, a többit meg kizárom. Ha mindent pontosan le akarnék fordítani amit olvasok, nyilván sokkal több időt elvenne, mint amennyit foglalkozni kívánok a dologgal. Ezért van hogy néha átsiklok dolgok felett.