Linux kernel: új fejlesztési modell

Kernel

Egyelőre nem lesz 2.7, a fejlesztés üteme viszont fel fog gyorsulni.... - ez a Linux kernel fejlesztésének rövid roadmap-ja



Tegnapelőtt zárult a Linux Kernel Summit 2004 rendezvény, ahol érdekes döntések születtek a Linux kernel fejlesztésének menetéről. A változások kicsit átalakítják a sok-sok éven át megszokott fejlesztési irányvonalat.

A dolog azzal kezdődött, hogy Greg Kroah-Hartman egy patchet küldött tegnap az LKML-re. A patch eltávolítja a devfs-t a 2.6-os Linux kernelből. Ahogy Greg K-H írta, a patch elküldésével tesztelni akarja az új kernel fejlesztési modellt. Mivel a kereskedelmi disztribúciók nem használják a devfs-t a 2.6-os kerneleikben, mivel annak kódja meglehetősen bugos, és mivel hosszú ideje karbantartó nélkül áll, úgy gondolta, hogy ideje megszabadulni tőle. Kérte Andrew Mortont, hogy tegye a patchet az -mm kernelfába, és ha úgy gondolja, küldje el Linusnak, hogy az a 2.6-os kernel része lehessen.

Többen is jelezték, hogy szerintük még nincs itt az ideje a devfs eltávolításának, és hogy ezt a lépést nem a 2.6-os stabil kernel közepén kellene megtenni, hanem majd a 2.7-es fejlesztői kernel fa megnyitása után, a fejlesztői fában kellene ilyen nagyobb horderejű döntéseket hozni.

Greg K-H ismét azzal védekezett, hogy csak az új, a Kernel Summit 2004-en megbeszélt kernel fejlesztési modellt próbálja ki.

Adrian Bunk levelében érdeklődött, az iránt, hogy mit takar a titokzatos ``új kernel fejlesztési modell''. Greg K-H levelében azt válaszolta, hogy az egész stable/development kernel fejlesztési modell megváltozott, és hogy bővebb infókért mindenki olvassa el az LWN.net összefoglalóját a Linux Kernel Summit 2004 rendezvényről.A listat tagok felhívták a figyelmet arra, hogy az LWN.net hivatkozott szekciója csak előfizetőknek érhető el... Adrian Bunk felháborodottan közölte, hogy ha a Linux kernel fejlesztésének ilyen fontos infói csak az LWN.net fizetős oldalaink keresztül érhetők el, akkor ez volt az utolsó napja az LKML-en. Mivel többen is felszólaltak az LWN.net-es információforrás ellen (pontosabban nem az LWN.net ellen, hanem az ellen, hogy csak ott érhető el az infó), Mike Snitzer bevágta a fizetős LWN.net oldal vonatkozó részeit.

Az idézetből a következők derültek ki:

- Linus elégedett a Linux kernel jelenlegi fejlesztésének folyamatával

- Linus nem érzi, hogy itt lenne az ideje a 2.7-es fejlesztői fa megnyitásának

- Bdale Garbee jelezte, hogy az emberek hiányolják a 2.7-es fát, mert szerintük a 2.6 nem stabilizálódott eléggé

- Andrew Morton közölte, hogy Linus és Ő kb. 10MB/hónap sebességgel fogadnak el új patcheket a 2.6-ba

- Andrew azt írta, hogy ez valószínűleg nem is fog változni, mert azt szeretné látni, hogy a 2.6 folyamatosan változik, fejlődik. Ahogy írta, az elképzelései szerint a disztribútorok feladata lenne a stabilizáció... A látomásaiban az szerepel, hogy a kernel.org-os kernel a lehető legfunkciódúsabb és leggyorsabb kernel lesz, amely nem feltétlenül a legstabilabb is egyben

- Folytatódik a patchek áradata a 2.6-ba, és Andrew szerint nagyon kevés olyan patch lesz, amely elvetésre kerül

- Az sem biztos, hogy nem lesz API változás a 2.6 alatt. Andrew szerint az lenne a legjobb, ha az API változások a még a 2.7-es fa megnyitása előtt beépítésre kerülnének a 2.6-ba, mert így a két fa szinkronizációja sokkal egyszerűbb lenne

- A 2.7-es fa csak akkor lesz megnyitva, ha annyi experimental patch lesz, amely miatt már azt érdemes megnyitni. Viszont ha az megnyílik, akkor az a teljesen kísérleti, és destabilizáló patchek számára lesz fenntartva

Az LWN.net szekció csak egy hét múlva lesz publikus a nem fizető olvasóknak, így addig csak az LKML-en elszórt morzsákból lehet csipegetni. Mindenesetre érdekes az új fejlesztési modell, és reméljük, hogy valóban jó utat választott Linus és Andrew. Egy biztos, ezzel a módszerrel a fejlődés még gyorsabb válik. Kérdés, hogy ez mennyire megy majd a stabilitás rovására...

Arra alapozom, hogy pl. 3-4 ora futas utan puff, kikapcsol a gep, hogy megvedje magat, mert a kernel meg van rola gyozodve, hogy 45 fok van belul, ezert nem porgeti a ventilatort.

Arra alapozom, hogy ha arra mereszelek gondolni, hogy betoltom a psmouse modult, ami a laptop touchpad-jat kene kezelje, akkor kernel oops-tol kezdve egyszeru nem tudom kezelni a hardvert, csokolom uzenetig barmi johet, de altalaban fagyi van.

Ezen kivul szamos dolog, ami 2.2-ben, 2.4-ben mukodott, az nem mukodik. Hogy mast ne mondjak, pl. a psmouse modul a korabbi kerneleknel beugrik magatol, ha pl. gpm-et, vagy X-et inditok. Itt a korai 2.6-okban es a 2.5-ben meg nem pusztult bele a kernel, de kezzel kellet behuzni, mert nem veszi eszre, hogy be kellene toltenie.

Ami most persze tiszta szerencse, mert egyebkent boot utan rogton jonne a dump es kapcsolhatnam ki.

Hat, most hirtelen ennyi. Sajnos igazan tesztelni meg nem volt modom, mert nem mukodik.

Azt lattam, hogy a 2.4-ben volt az infra chipsetemhez driver, 2.6-ban mar nincs.

Meglatjuk. Lesz majd gondolom idovel hasznalhato is.

A becsiszolasrol meg csak annyit, hogy a gyari kernel is ugyanugy behal a psmouse-ba.

Szoval atomstabil.

Viszont az is igaz, hogy egy van egy regi PIII-as asztali gepem, kikapcsolhatatlan ventilatorral, nincs benne belso eger, nincs benne infra. Szoval ezt az igazan konzervativ gepet elviszi a 2.6.

Csak ez a gep most mar honapok ota ki van kapcsolva, mert nem az _a_ gepem. Hanem emez.

>Arra alapozom, hogy pl. 3-4 ora futas utan puff, kikapcsol a gep, hogy megvedje magat, mert a kernel meg van rola gyozodve, hogy 45 fok van belul, ezert nem porgeti a ventilatort.

A notebookom napi 12-16 orat megy 2.6-os (2.5.70 ota korabbi cikk) kernellel es nem kapcsol ki (ez a masodik notebookom, elotte egy IBM Thinkpad-om volt az sem kapcsolt ki). Jelenleg is errol irok 2.6.8-rc2-es kernellel.

>Arra alapozom, hogy ha arra mereszelek gondolni, hogy betoltom a psmouse modult, ami a laptop touchpad-jat kene kezelje, akkor kernel oops-tol kezdve egyszeru nem tudom kezelni a hardvert, csokolom uzenetig barmi johet, de altalaban fagyi van.

Ilyen problemam sincs, tokeletesen mukodik a notebookom touchpadja, az elozo notebookom trackpointja is ment, es a ra dugott USB eger is mukodik. Akar egyszerre is a touchpadra. Akar ugy is, hogy csak az X inditasa utan dugom ra a gepre. Felismeri es mar megy is.

>Ezen kivul szamos dolog, ami 2.2-ben, 2.4-ben mukodott, az nem mukodik. Hogy mast ne mondjak, pl. a psmouse modul a korabbi kerneleknel beugrik magatol, ha pl. gpm-et, vagy X-et inditok. Itt a korai 2.6-okban es a 2.5-ben meg nem pusztult bele a kernel, de kezzel kellet behuzni, mert nem veszi eszre, hogy be kellene toltenie.

Nemtom mert nekem bele van forditva a kernelbe.

>Ami most persze tiszta szerencse, mert egyebkent boot utan rogton jonne a dump es kapcsolhatnam ki.

Nekem meg nem dumpolt el a kernelem, sot 10 szerver minimum megy 2.6-tal nalam, meg egyket desktop es notebook is.

>Azt lattam, hogy a 2.4-ben volt az infra chipsetemhez driver, 2.6-ban mar nincs.

Passz, nekem megy a wireless kartyam, megy a firewire, megy az onboadr sound es LAN, megy a DVD iras, megy az ATi 3D tamogatas, megy az Unreal 2004, megy az USB mass storage, megy a digitalis fenykepezom, megy az NVidia kartyam, megy a tv tuner kartyam, ... Nincs olyan eszkozom ami megy 2.4 alatt de nem megy 2.6 alatt. Biztos furcsa, de igy van...

Egyebkent sokan bebuktaznak a 2.6-tal, mert egy kicsit mashogy kell kernelt konfiguralni. Lehet, hogy csak el kene olvasni a Post Halloween doksit? (most irom le 100121-edszer, lehet neked is segit :-), masnak mar segitett)

>Szoval atomstabil.

Igy igaz. Nalam az. Biztos bennem van a hiba :-)

De gyere el a Linux Konfra, elviszem a notebookom, ahol akar meg is mutathatom...

***** lenne, ha ISA tamogatas, vagy ugy egyatalan, a regebbi gepek tamogatasa kimaradna 2.6-bol. A 2.6, annak ellenere, hogy csomo uj dolog van benne meg minden, sokkal jobban elfut a laptopomon, mint a 2.4. Pedig osszevissza van 4Mb memoriam, egy mezei 486-oson. Erezhetoen gyorsabban valaszol a rendszer (lehet, hogy egy hatterben futo cron cucc 2x annyi idot vesz el, de az abszolute nem erdekli a mezei usert). Szoval 2.6-ban az interaktivitas sokkal jobb lett kis gepek eseteben is.

Amig meg van, aki hasznalja (es fixalja a drivereket, etc) a regi cuccokat, miert baj ha azt is tamogatja a kernel? Ha nem kell, nem forgatod bele, es mindenki happy :)

Ha az lenne hogy csak a legmodernebb, legtobbett hasznalt dolgok lennenek benne, akkor futna osszevissza x86-on es kesz. Nem lenne jo.

( anr | 2004. 07. 22., cs – 10:00 )

Ez erdekes.

Foleg azert mert a disztro keszitok eddig azt mondtak, hogy akar a stabilitas rovasara (backport, a foagba be nem kerult patch-ek) is, de nekik kellenek a legujabb featurek.

A linux kernel mar eddig is a legterjedelmesebb feature listaval rendelkezett, mi lesz itt ezutan?;))

( Hunger | 2004. 07. 22., cs – 10:33 )

Egy kicsit olyan érzésem van, hogy ezután a vanilla kernelt a lehető legkevésbé lesz érdemes használni, mert a fejlesztők úgy gondolják, hogy elég ha a disztribútorok által kiadott kernelek a megfelelően stabilak.

( buga v | 2004. 07. 22., cs – 10:38 )

Mokas, eppen mostanaban beszelgettunk arrol, hogy milyen jo, hogy a 2.6.xx ilyen stabil ellentetben a neki megfelelo 2.4.xx szeriaval, ami meg 2.4.14 koraban is milyen problemas volt, es hogy ez jo, mert a userek hamar atternek a kellemes feature-ok es cserebe kapott stabilitas hatasara, oszt' most meg ez a hajo is eluszni latszik.

A 2.6 szerintem sokkal stabilabb mint a 2.4

En nem akarom bantani Marcelo Tosatti-t, de ot megtenni kernel karbantartonak nem volt egy jo lepes. Miutan Alan Cox elengedte a kezet, sok minden nem is tortent a 2.4 korul. Viszont Linus meg Andrew tudjak mit csinalnak. Egyebkent ok szallitanak egy alap kernelt, a disztributorok meg ugyis atalakitjak. Szerintem nincs olyan disztributor aki vanilla kernelt csinal. Aki meg kernel.org-os kernelt hasznal, az ugyis tudja miert teszi. Valoszinuleg az mar a power user kategoria, es el tudja donteni, hogy melyik verzio felel meg neki, es melyik az amit jobb nem hasznalni. En nem felek ettol annyira...

Hát azért ez szerintem nem egészen így van IMHO. Gondolom nem vagyok egyedül azzal, hogy én is kernel.org-os kernelt használok a debianos gépeimen. Ennek ellenére nem lógok a kernel listán és nem tudom naprakészen, hogy az egyes verzióknak mik a gyengéi is az előnyei.

Szerintem ebből az "áldozzuk föl a stabilitást a sebesség miatt" hozzáállásból még lesznek nagy anyázások.

( uid_228 | 2004. 07. 22., cs – 10:59 )

Azt tudja egyébként valaki, hogy a 2.6-osban az usbfs mount opcióit kijavították már? Régebben ti. egyáltalán nem vette figyelembe. Ami nem kritikus hiba, de idegesítő. Pl. emiatt csak rootként tudtam a digikamerámról a képeket letölteni. :I

Nem tudom, nekem spec az olyan dologok nem hianyoznak a 2.6-bol mint az ISA tamogatas, vagy devfs... Ki kene szorni a banatba. Akinek regi gepe van hasznaljon 2.2-t, 2.4-et...

Szivesebben latnek inkabb PCI-X, Gigabit, Hotplug, Wireless, Firewire, USB2, stb. dologkat mint azt, hogy valaki fixalta a az Old CD-ROM szekciot, vagy eppen uj utos hangkartya drivert irt az SB 16-hoz.

Ok megcsinaljak az alapot, a disztributorok meg becsiszoljak. Vagy olvasod a listat es alakitod te maganak.

( Névtelen (nem ellenőrzött) | 2004. 07. 22., cs – 11:51 )

Miért érzem úgy, hogy kezd egy kicsit Windows-os felfogásba átmenni: Minél több új dolog, de nem érdekel, ha összedől miatta az egész, vagy a rossz leprogramozás miatt nem megy az egyik a másiktól.

Elolvasva a pontokat nekem személyesen nem tetszik a leírt feljesztési irányvonal, bár nem távolítanék én se semmit se a kernelből (mert végül is magadnak állítod össze a kernelt, így azt teszel bele, vagy szedsz ki, ami neked tetszik, s támogatva vannak a régi dolgaid is, miközben nem kell az újdonságokról se lemondanod), mégis össze vissza minden patchet elfogadni, végiggondolás nélkül, hogy kell e, vagy hasznos e a kernelnek, vagy leszarjuk, hogy stabil marad e tőle a kernel? Nos, ez nekem kicsit unszimpatikus.

Szerintem a Linuxnak nem kell reklám, eddig is szépen terjedt, nem kell meglöketni sok sok feature-val, ami aztán a rendszer instabilítását okozza majd. Én maradnék azon mellett, hogy jöhetnek a patchek, meglessük őket, s ha jó a kernelnek, jöhet, de nem öszevissza "mindent bele" akció...

>Elolvasva a pontokat nekem személyesen nem tetszik a leírt feljesztési irányvonal, bár nem távolítanék én se semmit se a kernelből (mert végül is magadnak állítod össze a kernelt, így azt teszel bele, vagy szedsz ki, ami neked tetszik, s támogatva vannak a régi dolgaid is, miközben nem kell az újdonságokról se lemondanod), mégis össze vissza minden patchet elfogadni, végiggondolás nélkül, hogy kell e, vagy hasznos e a kernelnek, vagy leszarjuk, hogy stabil marad e tőle a kernel? Nos, ez nekem kicsit unszimpatikus.

Abszolute nem errol van szo. Andrew Morton az elso ember Alan Cox utan, aki gondolkodva fogadja el a patcheket, es nem fel azokat elvetni sem, ha nem jok. Volt mar olyan nem is egyszer, hogy az egyik -mm -be bekerult egy patch, de ket nap mulva ugy ropult h laba nem erte a foldet, mert nem volt jo.

Nem arrol van szo, hogy azonnal bekerulnek a mainline kernelbe a dologk. Az -mm fa egy eloszuro, ha azon atmegy akkor bekerulhet (ez se biztos, mert Linusnak ra kell bolintania, es o elegge konzervativ ebben a temaban). Max annyi fog tortenni, hogy egy uj utemezoert nem kell 2 evet varni, hanem esetleg par honap teszteles utan bekerulhet.

Egyet nem szabad elfelejteni. Regebben rengeteg hobbi fejleszto dolgozott a Linux kernelen. Akkor indokoltabb volt a hosszabb teszt ciklus. Most meg szamos olyan nagy ceg ad kodot a Linuxba, ami magaban is teszteli a cuccokat, es amikor elkuldesre kerulnek, azok mar tobbnyire jol hasznalhato dolgok. Jol mutatja Andrew jo hozzaallasat pl. a Reiser4 filerendszer. A Reiser csapat szerint mar februarban bekerulhetett volna az -mm-be de meg mindig nincs benne.

>Elolvasva a pontokat nekem személyesen nem tetszik a leírt feljesztési irányvonal, bár nem távolítanék én se semmit se a kernelből (mert végül is magadnak állítod össze a kernelt, így azt teszel bele, vagy szedsz ki, ami neked tetszik, s támogatva vannak a régi dolgaid is, miközben nem kell az újdonságokról se lemondanod),

Most akkor visszakerdezek: attol hogy uj dolgok vannak benne nem lehet regebbi kernelt hasznalni? Vagy nem lehet kihagyni forditaskor az uj dolgokat? Dehogynem. Csak igy meg van az eselye, hogy tobben tesztelik a friss dolgokat. Ha nem jo, barmikor visszalephetsz egy vagy tobb kernel kiadast... A valasztas meg van itt is... Senki nem mondta neked, hogy a 2.6.7-et kell ma hasznalni, hasznalhatod a 2.4.2x-et is...

Köszönöm szépen a felvilágosítást a hozzászólásom első részében leírtakkal kapcsolatban, viszont a másodikhoz lenne még egy-két gondolatom:

Először is nekem pont az volt szimpatikus a Linuxban, hogy a verziószámok növekedésével a fejlettség nőtt, de nem lett kevesebb a támogatottság. Úgy értem, hogy a 2.6.7-es kernelt akár egy 386-os architektúrára is felrakhatom, mert benne van az összes olyan támogatott driver, amivel akár egy nagyon régi gépet is működtetni tudok a legújabb kernellel, de a legfrankóbb gépen is ez futhat. A régebbi kernelek esetében viszont (ugye a fejlődés átka, hogy a régi általában feledésbe merül) nem kerül bele nagyon sok újdonság (erről régebben volt itt is szó, kell e backport, vagy sem), így bár összetudnék ugyanúgy állítani egy régi gépet (486 pölö) a régebbi kernelből, de mégis lehetnek benne olyan hibák, ami miatt külsőleg érzékeny egy támadásra. (Mondok egy példát: 486-os gép ISA-s hálókártyával tűzfalként üzemel, vagy 486-os, ISA kártyával netet böngészik).

Én személyesen sajnálnám, ha kikerülne egy régi támogatás belőle, hisz erről szól a Linux: Építsd magadnak!, bár az is igaz, hogy előbb utóbb el fog érni a kernel is egy olyan nagyságot, ahol már nem lehet tovább növeszteni, s keményen ki kell szedni belőle ezt-azt. (Bár erre az lehetne a megoldás, mint a disztribúciók esetében, hogy architektúránként egy-egy kernel csomag... Külön egy kernel pölö 68XXX-re, egy külön S390-re, egy x86, és x86_64-re, stb... Ezzel lecsökkenne az egy architektúrára írt kernel nagysága...)

A devfs-nek nincs evek ota karbantartoja, es van helyette sokkal jobban mukodo alternativa (udev). Folosleges olyan kodot gorgetni, amelyikkel a kutya nem foglalkozik, csak bloat lesz amit nehez karbantartani.

Vannak olyan ISA drivereket, amiknek szinten nincs karbantartoja, es nincs aki az API valtozasokkor portolna kernelrol kernelre. Miert? Mert osszesen 3 ember hasznalja a vilagon. Ekkor azt szoktak mondani, hogy ha kell, allj neki karbantartani. De ez igy van a BSD-knel is, es Microsoftnal is. A Win2k megjelenesevel szamuztek egy rakas LPT, soros, ISA, meg mittudom en mit a kernelbol (legacy hw, mondtak ok). Nem is volt hasznalhato utana sok regi eszkoz. Ez a fejlodes egyik velejaroja.

Tudom, ez már csak filozófiai kérdés: de tényleg ez a fejlődés útja? Nem hiszem, hogy a régit el kellene dobni, csak mert régi volt. No meg így a közös tudás is megmarad, nem merül feledésbe. Nekem az tetszett a Linuxban, hogy a kernel "az öregekkel" együtt fejlődik, és nem felejti el a régit. Főképp Linuxnál nem tartom jogosnak ezt az irányvonalat, mert a Linuxnak nem áll anyagi érdekében, hogy rákényszerítse a felhasználóját, hogy megvegye az új vasat, hanem támogatja a régit is. (Miután a Linux esetében a fejlesztés nem a profittermelést célozta meg, ennek ellenére mégis milliárdos üzleteket tudhat maga mögött. Egyébként jó, hogy mondod a BSD-t: Melyik támogat aránylag jól egy régi 5x86-ost (486-133)? )

Én személyesen egy éve foglalkozom Linuxxal, s még nagyon keveset ismerek ahhoz, hogy szűk időmben számomra fontos programok fejlesztésébe, vagy bármibe is beleszóljak. Szerintem a tudás megillet mindenkit, bármilyen ellenjavak nélkül is, s elméletileg az egész OpenSource erről szól, nem?

( szaty | 2004. 07. 22., cs – 12:53 )

Tényleg kezd egy kicsit Winowsos beütése lenni a dolognak. Ez az amiből semmi jó nem fog kisülni. Ezáltal a kernel egy összevisszaság lessz nem egy tervezett jóláttekinthető (ezáltal jól javítható) kód, pedig szerintem ez kéne.Ezzel a stabilitást fogjuk föláldozni. Az MS is rájött hogy jobb ha a kernel fejlesztését elkülöníti a többitől, pl a Windows Longhornt így ejleszti. Most majd mindenki blerakhatja a Linuxba a kódsorait, amit egyedül minden kordináció és összehangolás nélkül otthon összedobott. Úgyvettem észre hogy a gyártók mostmár a drivereket maguk megírják Linux alá is nem a linuxosoknak kell erölködni pontosabban kéne mert ha jól értettem most ez lessz. Inkább a jelenlegi kódot kéne továbbfejleszteni a rosz, esetleg lassú részeket kicserélni.

Ezzel nem arra célzok hogy nem kell új tartalom a kernelbe csak nem kéne minden szart betenni a hivatalos fába., pl szerintem a ShadowCopy hiányzik a nagyvállalatoknak.

1.) Egy fejleszto addig fejleszt egy bizonyos kodot ameddig motivalt. Nincs annal frusztralobb erzes, mint amikor dologzol valamin, amit a kutya nem hasznal. Igy ezek a dolgok elavulnak. A fejlesztok atallnak a Vesa Local Bus fejlesztesrol a 2-3 generacioval ujabb PCI-X-re, mert azt millioan fogjak hasznalni, az utobbit meg 200-an hasznaljak aktivan. Azok a kodok, amiket nem tart karban senki csak zavarok. Miert? Mert az emberekben fals hitet kelt, hogy hasznalhato a kernellel. Majd amikor hasznalja, kiderul, hogy nem mukodik, mert 3 eve nem nyult hozza senki, vagy egy uj kernelben mar le se fordul (sok ilyen volt a 2.6 elejen), akkor mi van? Annyira megvaltozott korulotte a kernel, hogy egyszeruen mar nem mukodokepes, mert mondjuk nem tudja hasznalni a kernel ujabb infrastrukturait, stb.

Mivel nincs olyan aki jelentkezne a karbantartasra, el kell tavolitani. Vagy elo kell allnia egy olyan embernek, aki ezt kezben tartja, stb. De ilyen ember nem nagyon lesz. Miért? Goto 1.)

Nekem időm hiányában, tudás hiányában nincs lehetőségem fejleszteni, de így is próbálok segíteni ott ahol tudok. Próbálom megismertetni az emberekkel amit csak lehet, csak az a gond, hogy miután pénzből élünk, legtöbb időnket a munkahelyen töltjük, s sajnos nem mindenkinek engedik meg, hogy saját hobbijainak éljen munkaidőben. Kevesen mondhatják el, hogy olyan munkát végeznek, amit még szeretnek is, bár ez az én tapasztalatom. (Frusztrációról annyit, hogy én is csináltam már apróságokat, amit a mai napig kutya sem használ, mégis számomra jó érzéssel tölt el, hogy tessék, én még ilyet is tudok/tudtam, s ha lenne rá igény, szívesen leporolnám megint...)

Azok a kódok, amik már le se fordulnak a kernellel, nos azokért tényleg nem kár, de ha működik vele, s stabilan, miért ne maradhatna benne?

>(Frusztrációról annyit, hogy én is csináltam már apróságokat, amit a mai napig kutya sem használ, mégis számomra jó érzéssel tölt el, hogy tessék, én még ilyet is tudok/tudtam, s ha lenne rá igény, szívesen leporolnám megint...)

Hat ez az... hogy le kell porolni. Ugy nem lehet egy ilyen dolgot csinalni, hogy nincs visszajelzes, es nincs teszter kozosseg.

>Azok a kódok, amik már le se fordulnak a kernellel, nos azokért tényleg nem kár, de ha működik vele, s stabilan, miért ne maradhatna benne?

Nem hiszem, hogy szo volt olyan kodok eltavolitasarol, minek van karbantartoja, van felhasznaloi bazisa, es mukodik.

Stabil a 2.6?

En 2.5.5x ota nezem, es meg nem lehet atallni ra, minden ostoba baja van.

Szerintem kicsit hamar lett a 2.5-bol 2.6, es a laptopomon pl. a mai napig 2.4-et kell hasznaljak, mert szamos dolog nem megy a 2.6-tal, es pl. az ACPI tragyasaga miatt kb. 3-4 ora alatt tulmelegszik, es kikapcsol.

Vidam dolog ez. En azert orulnek egy stabil 2.6-nak, amiben legalabb a regi hibakat kijavitanak.

Most akkor visszakerdezek: attol hogy uj dolgok vannak benne nem lehet regebbi kernelt hasznalni? Vagy nem lehet kihagyni forditaskor az uj dolgokat? Dehogynem. Csak igy meg van az eselye, hogy tobben tesztelik a friss dolgokat. Ha nem jo, barmikor visszalephetsz egy vagy tobb kernel kiadast... A valasztas meg van itt is... Senki nem mondta neked, hogy a 2.6.7-et kell ma hasznalni, hasznalhatod a 2.4.2x-et is...

Majdnem igaz. Csak van par dolog pl. ami a 2.4-ben nincs benne, de jo lenne. A 2.6 meg nem stabil. Igyhat ha visszalepek a stabilhoz, hianyoznak dolgok, vagy megvannak, viszont a rendszerem megbizhatatlan.

Persze igazad van, a szervereken vidaman 2.4-et hasznalok a mai napig.

Stabil termeszetesen csak akkor lesz, ha mar nem a 2.6ban folyik az erdemi fejlesztes, nem jon uj feature, hanem csak bugfixek jonnek ki hozza (tehat abban az ertelemben, mint a disztribucioknal).

Ha a "nem stabilt" futas szempontjabol erted, akkor nekem kiszolgalon mas a tapasztalatom.

Ott, hogy nem csak olyan kamera van, ami USB blokk eszköznek látszódik, hanem PtP protokollal piszkálható. Amúgy egy Canon S50-ről van szó. Ha a /proc/bus/usb nem a megfelelő jogokkal van csatolva, akkor az itt megjelenő USB egysegéket csak a root tudja megnyitni és bármiféle műveleteket végezni rajta.

A probléma meg ott van, hogy fstab-ban erre:

usbdevfs /proc/bus/usb usbdevfs defaults,devuid=0,devgid=102,devmode=0660 0 0

a 2.4-es szépen fölcsatolja és a privilegizált csoport elérheti az USB eszközöket, a 2.6-os meg magasról sz*rik és semmilyen mount opciót nem vesz figyelembe. Bravó. :I

A szomorú az egészben egyébként az, hogy a hibát tavaly szeptemberben már fölfedezték, én valahogy január tájékán botlottam bele, és még akkor sem volt javítva!

Éljen a gyors kernelfejlesztés! :I

Azt hiszem megyek, és megnézek egy BSD-t magamnak. :)))