Co se to dělo s kernelem Linuxu? (diskuse)

[thingie]

Ona mi (a nejen mi) .23 rozbila (přirozbila) suspend do paměti, wifinu a další čtvrt milión věcí, takže jí je třeba spravit...

[Cohen]

No že se chyby opravují, to je jasné. (Díky všem, kteří to dělají. Patří jim mé srdečné díky.) Proč ale musí na stabilní větvi vyjít během několika hodin sedm opravných verzí? Od vydání 2.6.23.1 uplynulo skoro pět týdnů. Snad by se tedy dalo 2.6.23.2 vydat ještě o pár hodin později, ale se všemi opravami najednou, ne?

[David Watzke]

Jestlipak by se našel nějakej úchyl, kterej je všechny stihnul zkompilovat a nabootovat (ještě když bylo každý jedno aktuální)

[pic]

kdybys ten dotaz nepokládal Ty, tak bych o jednom věděl

[Pavel Půlpán]

[stativ]

Podle haldy oprav v každém to vypadá, jako by opravné verze vytvářeli, ale zapomínali je uveřejnit. Nebo se jim to rozbilo.

[David Watzke]

Nerozbilo.

[outsider]

Pouzivat slovo "stabilni" ve spojeni s radou 2.6 je ... no rekneme "odvazne" Podle me cela rada uz od sveho vzniku vsechno mozne (progresivni, inovativni, apod.) jen ne "stabilni"...

[David Watzke]

To se mi na Linuxu líbí. Nehledí se tolik na zpětnou kompatibilitu, která pak často nové věci akorát brzdí, nemluvě o komplikovanosti kódu. A obvykle to s tou stabilitou není nějak špatný.

[Quest]

Jenže i zpětná kompaktibilita je pro uživatele důležitá.

[Luboš Doležel (Doli)]

Zpětná kompatibilita v jádře? A k čemu to ti uživatelé tak potřebují?

[jm]

Napr. k tomu, aby se po kazdem upgradu kernelu nerozesralo padesat externich modulu, ktere se museji opravovat porad dokola. Vyvojari kernelu jsou dokonce tak genialni, ze zcela zlikvidovali po leta funkcni gpio LIRC ovladac, jelikoz to bylo "nepouzivane". Vyborne, jen tak dal!

[Luboš Doležel (Doli)]

To je obvykle starost vývojářů distribuce.

Nebylo GPIO označené za obsolete už docela dlouho?

[jm]

To je obvykle starost vývojářů distribuce.

Protoze vyvojari v distribucich nemaji nic lepsiho na praci, nez furt dokola opravovat skody napachane aktualizaci jadra.

A ty rady, aby se tyhle moduly zaclenily do jadra, ty jsou taky k nezaplaceni. Kdyz uz se to nejakou nestastnou nahodou nekomu povede, tak to dopadne tak, ze po vsech "opravach" kodu obsahuje x-nasobek chyb oproti kodu, ktery byl mimo jadro. Protoze dosavadni vyvojari, co danou vec po leta vyvijeli, jsou evidentne nesvepravni pitomci, takze na jejich namitky a zduvodneni, proc je neco udelano tak, jak je, a ne tak, jak by panove od kernelu chteli, neni potreba brat zretel. Nedavny priklad je treba ivtv.

Nebylo GPIO označené za obsolete už docela dlouho?

Jiste, nejlepsi je pouzivanou vec smazat a na uzivatele hodit bobek. On tam ten kod totiz hrozne prekazel a bez jeho smazani by se kernel nepohnul z mista.

[Luboš Doležel (Doli)]

Nebylo GPIO označené za obsolete už docela dlouho?

Jiste, nejlepsi je pouzivanou vec smazat a na uzivatele hodit bobek. On tam ten kod totiz hrozne prekazel a bez jeho smazani by se kernel nepohnul z mista.

Už ani nepamatuju dobu, kdy gpio obsolete nebylo - víc než rok to v takovém stavu bylo. Jako náhrada je teď dev/event, byl dostatek času na přechod.

[jm]

Už ani nepamatuju dobu, kdy gpio obsolete nebylo - víc než rok to v takovém stavu bylo. Jako náhrada je teď dev/event, byl dostatek času na přechod.

Jiste, ono to sice nefunguje, ale na to sere pes. Hosi dekujem!

lircd-0.8.3pre1[21753]: lircd(cph06x) ready
lircd-0.8.3pre1[21753]: accepted new client on /dev/lircd
lircd-0.8.3pre1[21753]: could not get hardware features
lircd-0.8.3pre1[21753]: this device driver does not support the new LIRC interface
lircd-0.8.3pre1[21753]: major number of /dev/input/event5 is 13
lircd-0.8.3pre1[21753]: LIRC major number is 61
lircd-0.8.3pre1[21753]: check if /dev/input/event5 is a LIRC device
lircd-0.8.3pre1[21753]: caught signal
/etc/init.d/lircmd[21762]: start-stop-daemon: /usr/sbin/lircmd died
/etc/init.d/lircmd[21742]: ERROR: lircmd failed to start

[MJ]

A není to spíš bug v lircd?

[jm]

Jiste, protoze puvodni funkcni ovladac uz nelze zkompilovat, jelikoz nejaky genius odstranil potrebny kod z jadra, takze to je uplne evidentni, ze za vsechno muze lirc.

[MJ]

Pokud lircd spadne, aníž by zalogoval cokoliv rozumného, tak to nejspíš jeho chyba je, ovladač neovladač

[jm]

Jezkovy zraky, mluvim o tom, ze puvodni funkcni ovladac uz neni funkcni, protoze panove z jadra odstranili potrebny kod. Cokoliv dalsiho jsou nasledky tohoto nesmyslneho pocinani. Jestli je to tak tezke pochopit, tak to neres.

[MJ]

Pokud vím, bylo to především tak, že pánové od lirc se několik let sveřepě bránili návrhům na začlenění ovladače do jádra, takže upřímně řečeno, dobře jim tak

[jm]

Pokud vím, bylo to především tak, že pánové od lirc se několik let sveřepě bránili návrhům na začlenění ovladače do jádra, takže upřímně řečeno, dobře jim tak

Neni nad to zjistit si informace, nez tady zase plknes nejakou nebetycnou kravinu...

http://git.wilsonet.com/linux-2.6-lirc.git/

[MJ]

Milej pane anonyme, to, že se tak nakonec stalo ještě neznamená, že se tomu několik let nebránili (jak LKML, tak lirc-list už nějakých pár let čtu).

[pic]

neděje se teď zrovna náhodou něco podobného s video1394 a raw1394, nebo je to jen dočasný výpadek?

vždycky jsem mohl po modprobe video1394 a modprobe raw1394 používat dvkameru v pohodě a od jádra 2.6.22 jsem například u debianu v pytli - při tom jádro v ubuntu 7.10 je s podporou /dev/raw1394 přeložené,takže to nic dramatickýho být nemůže

jak jsou na tom ostatní distribuce používající novější jádro nevím - nemáte někdo zkušenost?

[MJ]

Kdyby v kernelu zůstávalo vše, co se tam někdy za jeho historii objevilo, byla by to pěkná džungle, ve které by se měl člověk přehrabovat mačetou a nikoliv textovým editorem. Někdy mám pocit, že umět mazat je důležitější než umět přidávat

Jako obsolete (a obvykle na dlouhou dobu) jsou takové věci označeny hlavně proto, aby se lidé, kteří ještě něco takového potřebují, ozvali. Pokud se rok neozvou tak, světe div se, mají smůlu.

[MJ]

Protoze dosavadni vyvojari, co danou vec po leta vyvijeli, jsou evidentne nesvepravni pitomci, takze na jejich namitky a zduvodneni, proc je neco udelano tak, jak je, a ne tak, jak by panove od kernelu chteli, neni potreba brat zretel.

Viděl jsem už pěknou řádku externě vyvíjených modulů a na téměř všech je vidět, že jejich základy pocházejí odkudsi z dávnověku, kdy ještě spousta věcí v jádru fungovala jinak, a od té doby jsou pouze záplatovány, aby chodily s novějšími kernely. Pitomost bych nikomu nepřisuzoval, ale jaksi málokdo, kdo není přímo zapojený do vývoje jádra, dokáže při starání se o své ovladače ještě sledovat docela zběsilé tempo vývoje zbytku jádra.

Při review kódu před začleněním do jádra také často vyjdou najevo nejrůznější bugy (například v základech shnilé zamykání v ReiserFS 4) nebo nepřenositelnost (ne každý ví, na co se lze spolehnout obecně a na co jen na i386). Proto si myslím, že začleňování do jádra většině driverů prospěje. Výjimky se samozřejmě najdou všude, ale podle nich bych nesoudil na funkčnost celého systému.

[Espinosa]

Kašlání na zpětnou softwarovou kompatibilitu kernelu i koncový uživatel může pocítit. Silně.

V mém případě to byl driver wifi karet s čipem RaLink, ten je základem velkého množství spotřebitelských wifi karet, populární Sitecom a další. Firma je open source friendly a vývoj linuxových ovladačů oficiálně podporuje. Ano, vývoj probíhá externě. Do verze 2.6.18 byla tahle rozsáhlá skupina hw podporovaná, šlapala přímo ukázkově, drivery byly součástí řady distribucí.

Od verze 2.6.18 se něco zlomilo. Vývojáři modulu začali pracovat na novém driveru, výrazně přepsaném (rt2x00, rt2500pci), nedostávalo se jim času udržovat starý. Vývoj nového se ale stále vleče, máme tu kernel 2.6.23 a stále to nefunguje jak má, většina lidí, včetně mě je závislá na prodloužené životnosti legacy driveru.

Některé distribuce, jako SUSE, to vzdaly a přestaly podporovat karty na tom čipsetu úplně. Takže v SUSE 10.1 to fungovalo, provedete upgrade na SUSE 10.2, těšíte se, co bude nového a vylepšeného, a ona zatím wifi přestalo fungovat úplně. To koncového uživatele naštve. Buď uměle zůstane u starého kernelu (s nefunkční hibernací) nebo oželí wifinu. Někeré distribuce, jako PCLinux, s tím nějak válčí a nadále udržují starý driver při životě, nenechávají uživatele na holičkách, ovšem při nezanedbatelném úsilí vývojářů, je pak méně sil na upgrade jiných balíčků a podobné věci. Takhle se jen posiluje štěpení a vzájemná nekompatibilit distribucí.

Z minulosti mě napadají změny v /sys a /proc, které způsobovaly nefunkčnost řady user end programů jako je KPowersave a podobné.

[Michal Kubeček]

Některé distribuce, jako SUSE, to vzdaly a přestaly podporovat karty na tom čipsetu úplně. Takže v SUSE 10.1 to fungovalo, provedete upgrade na SUSE 10.2, těšíte se, co bude nového a vylepšeného, a ona zatím wifi přestalo fungovat úplně.

Driver pro Ralink wi-fi v OpenSuSE 10.2 je, je jen potřeba nainstalovat příslušný balíček.

[Espinosa]

Ano, vím a používám. Naštěstí se našel dobrovolník co se toho ujal a objevilo v SUSE build systému. Ale funguje to jen s oficiálními kernely 2.6.18. O hladkém upgrade kernelu + ralink driver si nechte zdát.

Dělal jsem nějaké pokusy s novějšími kernely plus vnutit mu starý driver, nějaké jiné více experimentální balíčky, zkompilovat vlastní driver, zkusit nový driver r2x00 (rt2500pci), vždy se nakonec objevili menší či větší komplikace. Nakonec jsem to vydal a zůstávám u 2.6.18 :(

Nevíte jak na tom je SUSE 10.3? Díky

[Michal Kubeček]

Asi mi nerozumíte. Driver pro Ralink je v OpenSuSE 10.2 součástí distribuce, je přímo na instalačním DVD, není potřeba ho stahovat z BuildService nebo nějakého externího zdroje. Balíček se v 10.2 jmenuje wlan-kmp-default, v 10.3 rt2x00-kmp-default.

[Espinosa]

Balicek wlan-kmp-default je mi nejaky povedomy, ale funkcni driver jsem z nej nenainstalovat. Tusim je tam ten rt2500pci (nefunkcni, musi se explicitne blaklistovat), nebo jine modely Ralinku, rt61 a vyssi.

Ja urcite instaloval z jineho, rt2500-kmp-default-0.0cvs2006081715_2.6.18.2_23-1.1.i586.rpm (legacy driver) ten jediny bezpecne funguje. Podrobnosti: http://www.suseforums.net/index.php?showtopic=30330&mode=threaded

Jako bonus, tady je odkaz jak jsem ladil rt2500pci (neuspesne): http://rt2x00.serialmonkey.com/phpBB2/viewtopic.php?p=23759

Vy tu katu mate, vam to jede?

P.S. Koukam ze suser-jengelh nabizi balicky pro Ralink http://ftp-1.gwdg.de/pub/linux/misc/suser-jengelh/SUSE-10.2/i586/ rt2x00-kmp-default-2.0.7_2.6.23.1_900.ccj57-18.5.i586.rpm Ale mam stale obavu, ze je to ten novy driver (aka rt2500pci) co me zklamal, no treba uz to jede ;)

[Heron]

To není tak úplně pravda. Dnešní linux bez problémů instaluji i na 8 let starý HW. Kdyby se kašlalo na kompatibilitu, tak už bych to neměl dostat ani na x86 (nadsázka). To není jak Mac OS, který přišel společně s novým HW od Apple a na starý se kašlalo.

[David Watzke]

Měl jsem na mysli softwarovou kompatibilitu.

[Espinosa]

Pokud by se vrtali jen v implementaci a garantovali API, alespoň po nějakou nezanedbatelnou dobu, byl bych spokojený.

KDE mělo stabilní API po celou dobu verze 3, v dubnu 2002, tedy skoro 6 let! Nikdy jsem neměl dojem, že by to jakýmkoliv způsobem brzdilo jeho rozvoj. Ba naopak. Stabilní API jen přilákalo vývojáře dodatečných modulů, rozšíření a aplikací. A právě přívětivé desktopy jako KDE a jeho programy mě přivedli k linuxu, ne jeho jádro. Připomínek k jeho kvalitě bych měl více.

Vývoj Gnome moc nesleduji, ale hádal bych, že tam bude podobná situace co se API týče jako u KDE.

[alblaho]

No a windows mají stabilní API dvacet let. Což je rozhodně jejich výhoda. Na druhou stranu je to díky uzavřenosti, oni to takhle dělat musí a stojí je to nemalé prostředky.

[alkoholik]

Coze?
Doplnte si prosim vzdelani na http://www.joelonsoftware.com/articles/APIWar.html

[MJ]

Pokud by se vrtali jen v implementaci a garantovali API, alespoň po nějakou nezanedbatelnou dobu, byl bych spokojený.

Možná nebyl, když by se brzy ukázalo, že nějaký nový driver nelze do jádra přidat bez změny API Mezi KDE a jádrem je bohužel ten podstatný rozdíl, že zatímco KDE žije ve svém vlastním světě, kde si volí axiomy, jádro se musí umět přizpůsobit stále se vyvíjejícímu hardwaru.

Jistě, problém lze obejít tak, že zavedete kopii původního API a změníte jen tu, ale to je, slušně řečeno, čuňačina a cesta, ačli dlážděná úmysly z nejčistších, vedoucí kamsi pod zem.

[jm]

Greg se definitivne zblaznil... A jeste ta logika, proc bezpecnostni zaplaty nejsou v 2.6.23.2 ale 2.6.23.8? Ach jo.

[Robert Krátký]

Třeba proto, že se týkají i věcí, které upravují předchozí patche?

[jm]

Bezva, takze kdo chce mit pouze nederavy kernel, tak si ho rozesere stovkou dalsich nesouvisejich patchu a pak se bude vrtat v regresich. To je fakt nadhera.

[MS]

Windows Vista, nejlepší operační systém planety se prostě povedl. Nezbývá než říci, wow

[frEon]

demence

[MS]

Tak to máš blbý.

[Pavel Půlpán]

Tady jeste nekdo veri na pohadky... ja ci taky!

[Robert Krátký]

Asi je načase, aby ses zapojil do přípravy -stable patchsetů a o trochu své moudrosti s Gregem podělil.

[MS]

Tady měl někdo k obědu vtipnou kašičku. Dej si zpět do pusy dudlík a běž spát. Jinak díky za radu...

[Max]

Hehe, dnes je to tu samej vtipálek ... :D
Zdar Max

[David Watzke]

Lepší než přejíst se rumovýma pralinkama, chytráku. To totiž nebyla reakce na tebe.

[MS]

Jak koukám, tak tady nikdo nerozumí srandě, protože problémem Windows Vista jsou jen Windows XP. S těmi rumovými pralinkami to vážně nepřeháněj, všeho moc škodí.

[Pavel Půlpán]

Ty rumovy pralinky jsou na tobe docela uz znat...

[MS]

Určitě si chtěl napsat na sobě...:D

[Pavel Půlpán]

Nn... ja se zridil spis vcera slivovici nez nejakejma pralinkama.

[Quest]

Jo ta dává, o tom by mohlo spousta lidí vyprávět

[mess]

"Microsoft vytvořil nejlepší ochranu proti kopírování. Už nemám ani důvod Windows Vista krást." Tohle jsem četl kdesi na živě a musím říct, že to ten dotyčný vystihl dokonale (dokonce to byl Windowsák). Takže si myslím, že WXP nebudou jediným problémem Vist .

[Michal Kubeček]

Možná to ale myslel právě tak, že zůstane u Windows XP.

[trekker.dk]

2.6.23 je celý nějaký divný - přestalo mi fungovat tlačítko na bedně; při update z .1 na .8 jsem musel překompilovat modul pro nvidii (což normálně nemusím), alsactl hlásilo nějaký chyby při restore (což je divný, protože ovládací prvky by se mezi .1 a .8 měnit neměly)

Asi se radši vátím k 2.6.22.

[Zdeněk Štěpánek]

Souhlas, me zase prestalo fungovat generovani NBI image. Vzdy to slo, ale ted mi etherboot hlasi nesouhlasici CRC. Musel jsem nekde na zapadlem serveru (mluvim/pisu o Arch Linuxu) vylovil starsi jadro a s tim to jde bez problemu.

Zdenek