☰ Menu

Scene.hu

Magyar demoscene portál – grafikusok, zenészek, programozók alkotói közössége

Home Forums A Demokészítés művészete Programozás [szavazás] Linuxos demó kódolás Reply To: [szavazás] Linuxos demó kódolás

#4985
avatarpontscho
Member

Kb 3 napja néztem bele a 2.6 merevlemezvezérlődrivereibe, mert egy olyan problémával találkoztam, ami nem volt dokumentálva. Megijedtem. Sikerült orvosolni a dolgot a driverből megtudott információk alapján ugyan (egy régi Seagate merevlemez úgy gondolta, hogy a szabvány a Z, a lemezkezelő meg úgy, hogy Y.) 2.6-ba (onmagahoz kepest) mar egesz jol gatyaba raztak. A forráskód valóban okádék szerű kialakítású volt. De erről még nem dobjuk ki, mert a célnak egész jól megfelel. Nem csak a forraskod volt (?) okadek, hanem a kialakitott es hasznalt algoritmusok is. Azért írtam a kioktató szöveget, mert összemosod a linuxot az egyes többékevésbé elterjedt disztribúciók, és a kernel között. Gyakran kiragadott, csak 1-1 disztribre jellemő bugot próbálsz demonesztálni (Athináék után szabadon…) amik nem az összes linuxra, csak egy egy adott rendszerre jellemzőek, és a többi linux alatt tökéletesen működnek. Mint emlitettem, a linux gyujtonev. Masreszt az altalam eddig emlitett osszes problema – a debil altal “javitott” OpenSSL bugot leszamitva – disztribucio fuggetlenek, tok mindegy melyik elcseszett vacakrol van szo, a komponensek es inkompatibilitasok ugyanazok. Ergo nincs mit elkenni, viszont egyik altalam vazolt problemara sem volt erdemi reakciod. Innentol lehet ragozni ki mit ken. Na dehát ez megint milyen hülyeség már. Tipikus “nem működik a windows95ös hangkártyadriverem ikszpé alatt”. Ez van. Van egy erdekes diferencia a ketto kozt. Ugyanis – a peldadnal maradva – Win95 es Win98 kozott atvihetoek a driverek, viszont 2.6.24 es 2.6.26 kozott mar jo adag szerencse is kell. Ami vegyuk eszre csak ket minor verzioban kulonbozik. Hulyeseg, persze. Mint a linux kernel developerek szerint a stabil api. Last a stable-api-non-sense.txt a kernel forrasban. Amikor az oprendszer alapjait kicsit áttírják, akkor a driverek, és a rendszerközeli dolgok nem feltétlenül működnek együtt, várni kell, amíg hozzáigazodnak a programok írói. Ez windows alatt is így van, mindig is így volt, Nem igazan. Mert pl. a Windows XP driverek nagy resze egyutt mukodik a Windows2000-rel is, amig ugyanez ket, mar emlitett minor verzio kozott is ketseges. Kulonben nem lenne tele allandoan az osszes forum egy uj kernel release-nel, hogy “mar megint nem fordul az nvidia driver, az ati driver”, nem lenne masnap focim a HUP-on, hogy “Nem fordul a madwifi”, stb. ráadásul poénból az ember NEM változat se kernelt, se operációs rendszert. Kiveve, ami linux alatt gyakran megesik, lasd a TV tuner sztorimat, ha kenytelen ra. Mert mondjuk abban mar mukodik a hang is. Aztan jossz ra, hogy megint nem fordul a VMWare sajat kernelmoduljai kozul semmi. Sokszor kenyszerultem egy-egy ilyen ket kernel verzio kozotti broken API miatt hexaeditorral utanszerkeszteni a mar az elozo modulhoz leforditott modulokat, hogy legalabb addig mukodjon valami, amig ki nem jon a hivatalos javitas. Jellemzo pelda volt erre meg anno a 2.4.18 koraban a Guardware (ez egy magyar-svajci NATO beszallito ceg volt) altal gyartott biometrikus hardver illeszto moduljaira. Olyan fasza volt mar akkor is az USB API, es olyan rossz megallapodas volt a ket ceg kozott, hogy csak egy db binaris blob driver volt. Viszont a rendszernek mukodnie kellett, nem maradt mas, mint a disasm es a hexaeditor.Erdekes modon ket minor kozott sem a Windows, sem az OSX, sem mas kernele nem valtozik meg ugy, hogy tonkre tegye addigi munkad. Oly annyira, h pl. Solarison (a marketing duma szerint) a regi, ezereves 2.0-ara irt szoftverek is futnak az idei legutolso 10-es verzion is. Igy is lehet intezni a dolgokat. Igaz nem is lehet 5 fele utemezobol es 80 fele felig implementalt fs driverbol valasztani. Bar egy ZFS mellett kell a tokomnek az a fostalicska reiserfs, ext3/4. (Na, ez is megerne egy kulon sztorit, hogy mennyit ernek.) Ez zavar engem is, de épp elég gond van máshol is egy program fejlesztése során akár windowsban is, hogy ez a probléma lényegtelennek tűnik. Gondolj csak bele, linux alatt (jobbára) legalább más az inkompatibilis library-k neve. Aha, milyen remek is az, hogy nalad leforditod a dolgot, es mondjuk libxvidmode.0.so-t linkelsz. Aztan atviszed valahova, ahol ezt libxvidmode.1.so-nak hivjak. Gyakorlatilag a ket lib kozott NINCS semmilyen kulonbseg, csak a neve. Ez megtortent eset, ez utan voltam kenytelen atirni libdl-re az egesz betoltest. Es sajnos nem is egyedi. Windows alatt gyakran ugyanaz, elég csak az xp sp0, sp2, vista közötti horribilis, agytumort okozó faszkodásokra gondolni, hogy extrémebb esetekben egyszerűen nem csinál semmit a kibaszott függvény, mert kivették, vagy már mást csinál, mint 2 hete. A windows sp3 update során is az xp-s programok 10%-a megköszöni a lehetőséget, és lemond. Ettől a linux még nem rosszabb, sőt jobb, ott legalább közli, hogy melyik fájl hiányzik neki, vagy melyik szarozik. Nem hat. Mind kettoben jelen van a DLL hell jelensege. Mint bármely más operációs rendszer alatt, legyen az akár mac osx, linux, vagy épp window$, a verziók nem teljesen kompatibilisek, és az egyes libraryk és dll-ek is eltérhenek updatenként. Ez a jelenség nem linux függő, hanem minden operációs rendszert érint. OSX-en nem igy van. (Mino meglepetes.) Ott ugyanis meg major release eseten sem valtozott meg meg egy lib neve sem, csak mert verziot ugrott. Sot, kinosan ugyelnek arra, hogy felulrol mindig kompatibilis legyen az osszes framework az elozohoz kepest. Most pedig a gamek egy részének van külön xp-32, xp-64, xp 64 bites procival de 32 bites windowsra, vista-32, esetleg vista-64-es .exe is. Javaslom keress ra a kov. fogalomra: Universal Binary. Ezt a dolgot kulturaltan is meg lehet oldani, de normalisan eddig csak OSX-en implementaltak a dolgot. (Az NFSv4 ACL-kel egyetemben.) Ugyanez a -32, -64, es egyebb istenharagja linux alatt is pontosan megtalalhato, ugyanazon okbol, mint Windows-on. Linux alatt ezt inkább elegánsabban megoldották úgy, hogy a programokat általában forrásként adják, így minimalizálva a verziók közötti eltérésekből fakadó problémákat. Egyresz a forditas NEM megoldas. Harom okbol: a tokom akar mindent forrasbol feltenni es azok fuggosegeivel foglalkozni. Ugyanis a disztribuciokat pont emiatt talaltak ki, hogy ok majd ezt kezelik a kesz, hasznalhato rendszer remenyeben. Masreszt attol, hogy forrast adsz, nem kuszobolod ki azt a problemat, hogy detektalni kell, hogy az adott rendszerre mi van telepitve, ezert szuletett az autoconf/automake paros. Olyanok is. Nem veletlen, hogy a nagyobb projectek sajat konfiguracios scripteket irnak maguknak. Es ez NEM orvossag a broken API-kra.Harmadreszt nem mindenki akar src-t kiadni. Pl. a kis szamu hivatalosan kiadott normalis jatekok kozul eleg keves engine-je letezik forras formaban. Valamint az opensource softverek azon resze, ahol tamogatast lehet venni, mint pl. a Cedega, nem azonos azzal amit te otthon leforditani tudsz.Szerk: ez az e107 editor nagyon nem jo. De legalabb van edit button. :)

Ugrás a lap tetejére Ugrás a lap aljára