A SuSE bírálja azokat, akik backportolnak a 2.6-ból

openSUSE, SUSE, SLES

A SuSE Linux vezető technológusa azt nyilatkozta, hogy a Linux kernel 2.6-os fájából való backportolás (backport = újabb funkció, program visszaültetése egy régebbi környezetbe) ``rossz dolog'', mert negatívan hat a szabad operációs rendszer egységesítési törekvésekre.

A Red Hat korábban kijelentette, hogy egyelőre nem kívánja a 2.6-os kernelt felhasználni a terjesztéseiben, de emellett jelentős munkákat fektet a 2.6-os kernelből való funkciók visszaportolására. A SuSE munkatársa bírálta azokat, akik backportolnak.Juergen Geck múlt hét csütörtökön beszélt erről a problémáról a Real World Linux Conference-en. A beszédjében felhívta az iparban tevékenykedő, kulcspozícióban levő cégek figyelmét arra, hogy óvakodjanak az olyan praktikáktól, amelyek a nyílt forrású fejlesztések egységesítésének törekvéseit fragmentálhatják.

A Red Hat weboldalán nyomon követhetjük, hogy hogyan ülteti vissza a neki tetsző funkciókat a legújabb stabil kernel fából.

Az internetnews cikke a dologról itt.

A kérdés: valóban van szükség backportolásra?

-rc2-mm3

Ez azt hiszem mindent elmond. Az -mm fa egy kiserletezo fa. Ami abban bevalik, az megy a -mc (merge candidate) faba. Ami abban bevalik, az megy az -rc-be. Ami abban bevalik, abbol lesz a stabil kiadas. Azt hiszem nincs miert es nincs kinek szemrehanyni.

Fejlesszen az, akit azert fizetnek. Linus tobbszor is kifejezetten kijelentette, hogy ellene van a stabil kernelmodul interfesznek. Most akkor mi a fenet fejlesszek, ha barmilyen hasonlo patch-et gondolkodas nelkul kuld a /dev/null-ba?

Nem ertem ezt az ms fizet dolgot... A stabil kerneldriver interfesz szerinted Microsoft specifikus? Szerintem szoftvertechnologiai es okonomiai kerdes. Ha mindazon rengeteg emberoranyi munkat, amit a 2.6 kernel fejlesztesenel embereknek a driver-ek portolasara kellett forditani, mondjuk uj driverek irasara hasznosithattak volna...

Amugy, ha mar itt tartunk, teged ki fizet?

ATi és nVidia [bár csak nvnet] megy minden további nélkül, sőt, még debian/rules-t is csináltam [ehh, szal kopipészteltem vhonnan, és átírtam pár változó értékét benne...] nekik, h make-kpkg modules_image egyből csinálja őket... (; Szóval nálam a probléma nem jelentkezik, de mint írtam is az előző hozzászólásomban, h örülnék neki, ha másért nem is, de a többi ember életének egyszerűsítese miatt...

Egy nem clueless linux user gondolatai meg 2001-bol..

http://freshmeat.net/articles/view/216/

FSF-ek gondolatai a Universal Driver Interface-rol (ez kicsit tobb, mint egy stabil Linux kernel interface, mert lehetove tenne tobb operacios rendszer kozott ugyanazon binaris kernel hasznalatat):

http://www.gnu.org/philosophy/udi.html

Linus gondolatai:

"It's not going to happen. I am _totally_ uninterested in a stable ABI for kernel modules, and in fact I'm actively against even _trying_. I want people to be very much aware of the fact that kernel internals do change, and that this will continue."

http://kerneltrap.org/node/view/1758

Nem akarok nagyon Sun hivonek tunni, de a Solaris lassan tiz eve stabil driver interfesszel bir, es lehet, hogy nem fejleszti a fel vilag (bar a legujabb hirek szerint Kinaban 2-300 embert vettek fel Solaris x86 driverek fejlesztesere...)

( Chip | 2004. 04. 20., k – 09:37 )

Valahol meg lehet erteni a retek6ot, hiszen a 2.6-os szeria meg nem elegge kiforrott. Szerintem tul hamar adtak ki. De ettol fuggetlenul szerintem tenyleg nem szolgalja a fejlodest ha visszaportoljak az uj funkciokat. Sokkal tobb melo es ugyanolyan bugossa tehetik a 2.4-es kernelt mint a 2.6-ost. Szal majd a felhasznalok eldontik melyik a jobb -nekik-.

UFF

( Andrei | 2004. 04. 20., k – 10:53 )

Csak csendben kerdezem meg a SuSE-t (egyebkent minden elismeresem az ovek, mert tenyleg kepesek voltak versenykepes Linux disztribet es szolgaltatasokat felepiteni), hogy miert hagyta megfekudni a United Linuxot? Persze a valasz trivialis: a RedHat nelkul nincs United Linux. Fel kellene fogniuk, hogy az RH es a SuSE az a ket ceg amelyik a Linux sikerenek a kulcsa (nomeg persze az IBM, de az attetelesen).

Nem tudom, hogy az ilyen oldalvagasok hova vezetnek?

Andrei

( nevergone v | 2004. 04. 20., k – 11:37 )

Nem tudom, egyesek milyen módon bírálnak (negatívan) egy kernelt, akár 2.4.x, akár 2.6.x is az...

A backportolás...? Nos, ez kettős dolog:

Egyrészt jó, mert nem minden gépre lehet (érdemes) még 2.6.x -es kernelt tenni. Nem azért, mert a kernel rosszabb, hanem a gép gyenge, kicsi a tárterület (a 2.6.x -nek már böhöm nagy a mérete kicsomagolva), vagy egyéb paraméterek miatt. A 2.4 -es még elmegy, de a 2.6 -os már csak döcög maximum. Nos, ilyenkor jó, ha valaki az igazán hasznos lehetőségeket visszaportolja a régebbi stabil sorozatba is.

Másrészről viszont tényleg felesleges erőforrás-lekötés, hiszen azok, akik a backportot csinálják, alkothatnának valami mást is, most fejleszthetnék a 2.6 -os sorozatot.

Szerény véleményem szerint bár lelkes "2.6" -os vagyok, de azért nem kellene ilyen korán "kihalásra ítélni" a 2.4.x -es kernelsorozatot.

Nem értek egyet veled. A Linux sikerének a kulcsa nem a "nagy" cégekben, hanem a felhasználókban rejlik. Persze senkinek sem baj, ha a cégek halálra keresik magukat a Linux-on (elég megnézni a HP, és az IBM utolsó 3-5 negyedévének az eredményeit).

Viszont ha a felhasználók számára jodolog linuxozni (nekem jo, gondolom neked is), akkor a cégek akár a fejük tetejére is állhatnak, nem tudják hátráltatni a Linux terjedését.


A kommunizmus alapeszmeje, hogy mindenki dolgozik képességei szerint, és részesül igényei szerint.

Az opensource ezt _IS_ megvalósitja.

( LiRul | 2004. 04. 20., k – 11:46 )

Le lehet tölteni valahonnét a redhaték kernel diff-jét a vanilla kernelhez viszonyítva? Táncsak GPL alatt van...

A 2.6-os kernelben jelentek meg jelentos meretcsokkento featurek, szerintem ha valaki meretre optimalizal, akkor 2.6-al jelentosen jobb eredmenyt kepes elerni.

Nincs semmi problema 2.6-ra valtassa. Egyebkent a 2.4 sorozat stabilitasa a 2.6.19 ota hagy nemi kivannivalot magautan.

En 2.6.0-test6 -ta hasznalok 2.6 soozatot, kiprobaltam az osszes rc-t, sot az mm-ek nagyreszet is. Semmi gondom a stabilitassal.

Kihalas ugyben pedig: "2.0 is not dead", volt a neve a nemreg megjelent 2.0.40-es kernelnek. Aki az elavult rendszerek hive az hasznalja, aki nem az azokat meg nem kell felrevezetni. Nem hiszem, hogy a backportolast kepes valaki hibamentesen megcsinalni. Tuti instabilabb kernelt kap, mint amibol elindult.

( sz | 2004. 04. 20., k – 12:17 )

Részemről hogyha olyan alapvető dolgok backportolásáról van szó, mint pl O(1) scheduler vagy NPTL, akkor nem tartom jó ötletnek a backportolást. Ha driverek backportjáról van szó, akkor viszont örülök neki. A SuSE féle beszólásnak viszont egyáltalán nem örülök...

--

stabilitási kérdések 2.4 ill. 2.6 esetében: sztm nem lehet általánosítani. Van akinek a 2.6-tal jött el a kánaán, ugyanakkor valakinek viszont a pokol jött el (; Nekem pl. gond nélkül megvan a több hónapos uptime desktop ws-en 2.4.x-szel...

( k_laci | 2004. 04. 20., k – 12:40 )

Hi,

Ha jól tudom, akkor a RH által backportolt dolgok csak a saját kerneleikbe kerülnek bele, tehát a kernel.org-os vanillába nem.

Azt meg mindenki eldöntheti, hogy használ-e RH-et vagy sem.

Szabadság...


Laci

P.S.: Ha rosszul tudom, akkor kövezzetek meg :-)

( Toma_ | 2004. 04. 20., k – 12:50 )

Udv!

Azert erdekes, ha mernek a _stabil_ 2.6-ból backportolni, akkor miert nem hiszik el, hogy a stabil: stabil... Nem szakadt meg a stabilitastol a 2.4 sem szvsz.

Red6-ek meg az ntfs-t sem tettek read-only-ban sem a 9.0 kernelebe...

Mondjuk ilyesmit biralni a fenti indokokkal meg picit ciki szvsz...

"óvakodjanak az olyan praktikáktól, amelyek a nyílt forrású fejlesztésének egységesítésének törekvéseit fragmentálhatják"

8)

Toma_

"A 2.6-os kernelben jelentek meg jelentos meretcsokkento featurek, szerintem ha valaki meretre optimalizal, akkor 2.6-al jelentosen jobb eredmenyt kepes elerni."

Nekem ugyan nem tul fontos a kernel merete, de azert torekszem, hogy csak az altalam hasznalt dolgok legyenek benne, es amit csak lehet azt modulba teszek. Ezzel egyutt amikor a 2.4-rol 2.6-ra valtottam, akkor a bzImage kb. 800kB-rol 1050kB-ra nott, ugyanarra a vasra. Ezt persze onmagaban nem erzem problemanak, de mint jelenseg emlitesre melto. (Nyilvan nem egyezhet meg teljesen a ket kernel konfiguracioja, de torkedtem a funkcionalitasbeli azonossagra.) Szoval nem vitatkozni szeretnek, csak erdeklodesbol kerdezem, hogy ha most en meretre szeretnek (nem szeretnek, csak elmeleti a kerdes) optimalizalni, akkor azt hogyan tehetem meg, hogy ne csorbuljon a hasznalati ertek?

( _Joel | 2004. 04. 20., k – 16:51 )

Ami amugy a driver-ek backport-olasi dolgait illeti: eleg szomoru dolog, hogy evek ota nem bir kialakulni egy stabil kerneldriver interfesz, amihez azutan sok sok evig nem nyul hozza a tisztelt kernelfejleszto kozosseg. Micsoda dolog az, hogy minor kernelvaltozat novekmenynel is vannak olyan modulok, amik nem fordulnak le? Hat hol van itt a szoftvertechnologia, es miert kontarkodnak igy az interfeszekkel?

Bizonyos dokumentaciok illetve technologiak csak a nagy cegek szamara elerhetoek. Ha ezeket nem publikaljak a tulajdonosok, akkor szopas van.

Egyebkent az osszes nagy ceg tudja akadalyozni a linux terjedeset. Mas kerdes, hogy mit er el vele (semmi haszna nincs belole). Pl.:

- dollarmilliardos nagysagrendnyi penzt fektet pl. az OpenBSD-be, es Linuxos fejlesztoi eroforrasait atiranyitja az OpenBSD fejlesztesere. Ez ultraszopas.

- A szoftvergyarto leveszi a support listajarol a linuxot. Ez sem tesz jot az elterjedesnek.

Nem veletlen, hogy a Linux felviragzasa, a nagy multik inveszticiojanak eredmenye. A forditottja nem teljesen igaz.

Andrei

Baromira nem. A Red Hat az, amelyik általában húzza előre a többi disztribet. Még ha ez kellemetlenségekkel is jár. Eszembe nem jutna Red Hat-et használni, mert sok-sok új kísérleti technológiával csupa szívás (glibc, cutting edge gcc, nptl, utf-8 konzol stb.) De tuti hogy ha nem lenne egy ilyen viszonylag nagy felhasználói táború disztrib, amelyik így húzza előre a többi disztribet illetve a fejlesztőket (akik kapják a sok-sok bugreportot hogy mi nem megy a legújabb redhat alatt), akkor a többi sem tartana közel sem itt, ahol most tart.

Mindezek fényében persze abszolút nem értem, hogy miért nem akar 2.6-ra váltani a redhat. Lehet hogy a fedora kiválás stb. óta irányt váltottak.

2.6.5-rc2-mm3 olyan szép lefagyást csinált hogy csak na. Egy pdflush nevű processz elkezdte 100% hajtani a procit. Először utánanéztem mi ez processz, aztán gondoltam óvatosan rebútolok, de a kde-ből már nem sikerült kijelentkezni :-( Izgalmas pár másodperc volt, amíg bebútoltam egy régi kernelt, várva mit találok a merevlemezen. Szerencsére csak pár "értéktelen" file-t vágott haza (random tartalom). A filerendszer reiserfs.