arch + ati + kde4 #fail

ma frissített a xorg meg az open source ati driver.

a hatás nem maradt el link :))))

szeretném megköszönni mindenkinek, aki részt vett a fejlesztésében.

rendszer: arch (up to date @ 2009.11.01. 14:30)

most vagy reménykedem, hogy fixelik (vagyok-e olyan szerencsétlen, hogy csak nekem egy rakás szar?) vagy megpróbálok a rendszernek ártani azzal, hogy downgradelek, vagy próbálom elmagyarázni a fejlesztőknek, hogy tesztelni kellene egy ati-s gépen is nem csak intelessel, hogy feltelepül-e :D

btw elegem van ebből... ha nem utálnám annyira az ubuntut felraknam azt. bar ott se tokeletes a driver. de nagyobb felhasznalotabor, talan jobb support / fix

esetleg még kde bug lehet... de annak most nem frissült komponense és idáig működött. másnak tapasztalatok?

ps: szívesen irnék verziószámokat, de még nem tudtam elolvasni őket :) failsafe lesz ebből

Hozzászólások

arch meg kde4 nem is kell, ati önmagában fail.

--
"I tried to get into business school, but on the qualifying exams, I passed the ethics test."

nem flame-nek szánom, de se arch, se kde4 nem a stabilitásáról híres -éppen azért mert bleeding edge, ez ok is. De ez egy teszt rendszer így az én szememben, ha munkára kell, akkor miért nem választasz egy olyan distro-t, amelynek van több éves támogatottságú ága és támogatják is rendesen? azt egyszer belövöd és hosszú évekre van stabil működő rendszer aminél nem kell tartani attól, hogy ha holnap jön egy olyan frissítés, akkor mit csesz el vagy mit kell majd reszelni.

archbol van testing is de ez "stable" :) :D

tény amúgy, de ha meg pont olyanra van szükségem, aminek valami új verziójú lib a függősége akkor meg szopóág.

ez meg nyár eleje óta elvan úgy, hogy semmi probléma nincs vele. meg tetszik is a pacman :P

debian stable egy vicc, a testing meg testing. ubuntuk nagyon nem szeretik (talán az ati chipset) miatt a notim (még a live sem bootol be semmilyen kernel paraméterrel - noacpi és tsai. busyboxba dob). linuxmint volt még, ami tetszett, de ubuntu mivolta miatt az is felejtős

tény amúgy, de ha meg pont olyanra van szükségem, aminek valami új verziójú lib a függősége akkor meg szopóág.
Ja hát kérem az élet nem habostorta. Ez a kettő együtt nem fog menni. Soha. Semelyik disztróval. Kár is erről áhítozni. Ez még Windows alatt sem megy, csak ott kevesebb az olyan program, aminek új verziójú lib kell. Ugyanis ott (kis túlzással) minden program telepíti magának majdnem az összes library-jét és csak valami 1000 éves windows verziót tételez fel maga alá. Ja, hogy pár GB-ot simán fölesznek a kereskedelmi szoftverek, aminek a szabad szoftveres megfelelője csak 100 MB... Nos hát ez a világ tele van kellemetlen kompromisszumokkal és nem látok semmi varázslatos újdonságot, ami ezt egy csapásra megoldaná.
---
Internet Memetikai Tanszék

hogy tesztelni kellene egy ati-s gépen is nem csak intelessel, hogy feltelepül-e
Na most én erre elmondok egy tanmesét neked, ami velem esett meg nem is oly régen. Volt egy teremnyi gép, ami legalább 4 féle különböző időben történt beszerzésből származott, nagyjából 2002-2008 közötti időtartományban. Igen sajnos ilyen az élet, nem mondhatom azt, hogy cseréljük le az összes régit, mert akkor valahonnan kéne pár millió forintot is kerítenem, amiből ez megoldható. Mindegyikben Intel integrált videovezérlő, de persze különböző fajták (G845, G865, Q965, Q35, de talán még volt G965 is közte). Namost volt egy olyan bug, amitől az x _indőnkét_ segfaulttal elszállt. Annyira időnként, hogy én néha órákon át tudtam használni anélkül, hogy előfordult volna. Néha meg 5 percenként előjött. Ja igen, ez a bug csak a G865-ösöket érintette, a többin azóta sem sikerült reprodukálni. Egy elég gusztustalan frissítést kellett csinálnom, mert a hibát az xorg-video-intel fejlesztők kb 3/4 év után tudták kinyomozni és kijavítani és a fix már csak a kernel mode settinges driverbe került bele. Ehhez meg a kernelt is kellett frissíteni, meg elég sokminden mást is.

Mit kellett volna a csomag készítőnek tennie ebben az esetben? Fogni sorban az összes Intel videos alaplapot, 7 évre visszamenőleg, saccra ez legalább 15-20 félét jelent, és tesztelni mindegyiken az új drivert... hány órán át? mely funkciókat? milyen alkalmazásokkal?

Ez a fejlesztő feladata lett volna. Megjegyzem nem tudok haragudni Keith Packardékra sem, mert elolvastam a hiba részletes leírását és a fixet és bizony annak tényleg oka volt, hogy hónapokig nem tudtak rájönni az okára.
---
Internet Memetikai Tanszék

Nálam is bugzik, de csak effektekkel. a "megnyugtató" hogy opensuse11.2-ben is létezik a jelenség. Viszont ubuntuban nem.

Lehet csak sejtelmes megérzés, de a kms-sel kapcsolatban lehet.
nemsokára utánatúrok.

Szerk.: Ahogy sejtettem. bekapcsolt kms-sel nincs probléma. Viszont kms miatt kb a felére esik vissza a teljesítmény.

Ubuntuhoz tudok viszonyítani. Nem tudom, hogy ott ki volt kapcsolva a kms, és javították a hibát, vagy a kms-ben javították azt, hogy lassítson ennyit.

Mindenesetre gondolom ez a probléma nemsokára eltűnik az upstream-ből is, ha már ubuntuban reszeltek valamit.

némi kiegészítés: ha jobban megnézem az ábrákat, nálam ennyire nem esett szét a kép. És általában 3kattintás után ujraindul az X. Viszont kikapcsolt effektekkel semmilyen problémába nem futottam bele.

Az, hogy a kms-sel visszaesik a teljesítmény annyira nem is érdekes, hiszen az új driver annyit dob hogy még így is 50%-kal jobb lesz mint előtte. De ha már van mód rá, szívesebben látnám az uubuntuban tapasztalt több mint 100%-os teljesítménynövekedést.

lehet, hogy mégis vmi gtk-qt engine-nel van gond. még nem csúszott szét az X, csak konqueror megy

szerk.: megnyitottam a startot és megint elszúródott... vagy kde vagy driver...