[Frissítve] Érkezik a 2.8.0-s Linux kernel? Vagy a 3.0-s?

Kernel

Linus ma emlékeztette a fejlesztőket az LKML-en arra, hogy a 2.6.39-es kernel bejelentésében megemlítette, a jelenlegi beolvasztási időablak rövidebb lehet a szokásosnál, mert Japánba utazik a LinuxCon Japan konferenciára. Ezzel elkerülheti, hogy az -rc1-et Japánból kelljen kiadnia úgy, hogy a lassú laptopját kell használnia.

Linus egyre biztosabb abban, hogy a merge window korábban zárul. Valószínűleg vasárnap. Éppen ezért levelét figyelmeztetésnek szánta azon fejlesztők számára, akik az utolsó pillanatban akarták elküldeni neki a "pull" kérésüket.

Frissítés: Linus-nak egyre jobban tetszik a 3.0-s verziószám. A 3.0-s kernel kiadásával értelmesebb lenne szerinte áttérni a folyamatos verziószámozásra. Vagyis a 3.0 után jöhetne a 3.1, a 3.2 után a 3.3... Ezzel múlttá válna, hogy a páratlanra végződő kernelverziók "unstable" verziók.

Linus hangokat is hallott a fejében, amelyek azt mondogatták neki, hogy a kernelverzió számok egyre nagyobbak. Linus nem tartotta kizártnak, hogy eljött a 2.8.0 ideje. Mivel ha hangok bíztatják arra, hogy valamit tegyen meg, akkor azokra figyelni szokott.

Greg Kroah-Hartman Linusnak felajánlotta, hogy ha megteszi ezt, akkor egy általa választott üveg whiskey-t vásárol neki a jövő héten.

Igen, az idoalapu szamozas tenyleg sokkal ertelmesebb lenne ha megadott idokozonkent ugyis release van. Az ilyen ossze-vissza verzioszamozas pont a lenyeget oli meg a dolognak.
(Visszasirom a regi idoket, amikor meg tenyleg jelentett valamit a verzioszam, adj-isten fejbol tudtuk hogy melyik verzioban mi valtozott.)

En ennek hatarozottan orulok. Mert a feature-based releasek rettento szarok voltak, vagy irdatlan sokaig tartott, mire kijott. Kozben meg hasznalhattam szeteso devel kernelt, ha valami mokas uj dologgal akartam epp jatszani.

A mostani ido alapu kiadas nekem sokkal szimpatikusabb. Itt is van feature freeze, meg -rck, csak gyakrabban. Kisebb leptekben kenytelenek haladni, mintha egy egesz 2.7.x allna a rendelkezesukre, ami alatt kedvukre mindent eltorhetnek a kedves fejlesztok, aztan nem gyozik majd osszerakni ujra. Es lesz belole olyan borzalom, mint ami a 2.4 meg a 2.6 eleje volt. No thanks.

--
|8]

( gUHU | 2011. 05. 23., h – 22:56 )

És a 2.8 miről fog szólni? Mitől lesz több és jobb, mint a 2.6?

-- "Bízzál Istenben és tartsd szárazon a puskaport!" - Cromwell --
-- Sayusi Ando - http://sayusi.hu --

A verziószámozással egyetértek, de a stabilnak nyilvánítást szerintem a kiadás előtti verziókban felfedezett hibák javítása határozza meg. Persze feltételezem, hogy volt erre már ellenpélda.

A verziózást pedig nem tudom, hogy miért nem lehet dátumozással megoldani. A verziószám egy ilyen gyakori kiadású szoftvernél nem türközi rendesen a változások mértékét, akkor már inkább legyen dátum, a changelog meg úgyis megmondja, hogy mi változott az előző kiadás óta.

androbit.org - Informatikai portál és könyvtár

Mivel hobbiprojektről van szó ezért szó sincs marketingről. :P

Régebben szinte szemléletváltás volt verziószám léptetéskor. 2.2 és 2.4 között ég és föld volt. Ma már inkább csak léptet egy verzió számot és megpróbálja ignorálni a hozzászólók faszságát. (lásd Inigo-ét a 42-vel)

--
GPLv3-as hozzászólás.

( BaT | 2011. 05. 23., h – 23:11 )

Minek, ha semmi olyan változást nem hoz? Értem én, hogy a verziószámokat inkább csak az idő jelzésére használják (bár arra meg van egy remek jelölésrendszer, dátumnak hívják), de fő/alverziót váltani csak azért, mert a 40 túl nagy, picit erősnek érzem. Bár szerintem amilyen api változásokat hoz 1-1 kiadás, simán válthatnának alverziót kiadásonként.

--
Don't be an Ubuntard!

+1

Szerintem több bajt okozna egy alverzióváltás, mint amekkora hasznot hoz. Főleg, hogy a poénon kívül semmi haszna nincs. A Linux számára ez felérne egy Y2K problémával.

Különben is, akkor már miért nem 2.7? Nincs már külön fejlesztői ág.

Hát nooooormááális?!?! (És ezt nem viccből kérdeztem.)

( Csab | 2011. 05. 23., h – 23:11 )

A lassú laptop mit jelent? Nincs pénze dual-corera?
Vagy az otthoni 16 processzoros géphez képest lassú?

:)

mit lehet a puttyon utálni? relatíve stabil, és meglehetősen fícsörful...

pl. melyik másik linuxos/unixos terminálprogrammal tudod
- kapcsolatonként/on the fly tetszőlegesen változtatni a karakterkódolást?
- kapcsolatonként egyedi TERM változó értékeket és beállításokat használni?

Kényelmetlen. Legalábbis egy konsole-hoz képest.

Nálam rendszerint 15-20 terminál megy. A tab-ok nevei alapján tudom, hogy melyik mire jó.

Elég gyorsan tisztázódott, hogy nem akarok 15-20 ablakot.
Az X11 forwarding sem ment rendesen az exceed-del. Biztos be lehet állítani, de mivel a billentyűzetkiosztás sem jött be (del+backspace+home+end+pgup/down), hanyagoltam. Putty helyett exceed+kde nálam a nyerő.

Scroll egérgörgővel, rendes kijelölés, ablak átméretezés egérrel... szóval a GUI-ja kőkori.

Lehet, hogy be lehet állítani, de a konsole azonnal ment, mindenféle macera nélkül.

( subchee | 2011. 05. 24., k – 08:10 )

>>Linus hangokat is hallott a fejében
:(

vagy inkabb igy... 


3.1 -> 95 -> 98 -> ME   \
                         *-> XP (NT 5.1) -> 2003 (NT 5.2) -> Vista (NT 6.0) -> W7 ( NT 6.1)
... NT4 -> 2000 (NT5.0) /

valoban nagyon logikatlan...

ez kb olyan hasonlat volna amit te mondtal, mintha a kernel nevevel azonositanak a linux verziokat, es nem a verziojukkal

2.6.39 <-> "Flesh-Eating Bats with Fangs"
___
info

> ez kb olyan hasonlat volna amit te mondtal, mintha a kernel nevevel azonositanak a linux verziokat, es nem a verziojukkal

Pontosan. Epp ezert nem ertem, hogy mi a problema azzal, hogy 2.6.x-rol 3.x-re (vagy 2.8.x-re) ugrana a linux kernel? Ugyanezt teszi az osszes tobbi OS is idonkent, megis fel lett hozva az egyik peldanak, hogy arra kene valtani (feltetelezve, hogy az nem szenved ilyen 'hibaktol'). Pedig mint latjuk, de.

--
|8]

( uid_18247 | 2011. 05. 24., k – 08:58 )

subscribe

------------------------------------------
Egyetlen vi-parancsot ismerek, a kilépést.

( zoltanzoli v | 2011. 05. 24., k – 09:07 )

Ez a kernel fejlesztés egy káosz.

( uid_228 | 2011. 05. 24., k – 09:19 )

Inkább számozzák úgy, mint anno a SunOS-t. :) Pl. SunOS 4.1.3_U1B, esetleg még mögötte a patchlevel, mint egy 6+2 jegyű szám. :))

--
Web 2.0: you make the content, they make the money.

( uid_18247 | 2011. 05. 24., k – 09:28 )

Létezik egy Ivanhoe nevű sakk-engine, aminek a verziószámozása 1M-ről kezdődik, és visszafelé halad. :D

------------------------------------------
Egyetlen vi-parancsot ismerek, a kilépést.

( ubul_ | 2011. 05. 24., k – 09:56 )

Én arra lennék kiváncsi, ha idő alapú lenne a verziószám, akkor hogyan jelölnének egy backportolt security fix miatt frissült régebbi verziót (gondoljunk a RHEL-re vagy az Ubuntu LTS-re), és hogyan választanák szét az egyes fejlesztési ágakat.

( deucalion | 2011. 05. 24., k – 09:56 )

Én jobban örülnék egy stabil API -nak. Akkor tőlem belül azt túrnak és úgy ahogy akarnak. :)

Nem látom felsorolva azokat a függvényeket, amiknek a paraméterezése változott meg, azokat a függvényeket amik deklarációi másik headerbe kerültek át, vagy azokat a struktúrákat amikhez hozzáadtak/elvettek pár membert.

Múltkor csak a poén kedvéért lefordítottam egy kernel modult ami nem az aktuális kernelhez volt tervezve, olyan 5-10 fileba kellett belenyúlnom, a fent felsorolt esetekkel találkoztam. Konkrétabban volt egy függvény ami 3 paraméteres volt a forrásban, az aktuális kernelben meg már csak 2, volt pár fv (pl. kmalloc ha jól emlékszem) amikhez be kellett includeolni egy extra headert, és volt egy struktúra amiből kivettek 2 membert (jobb ötlet híján az érintett kódrészletet kikommenteztem). Így lefordult, betöltődött, de végül kipróbálni nem tudtam. Azért nem lepődtem volna meg, ha használat közben dobott volna a kernel egy panic-ot.

--
Don't be an Ubuntard!

És szerinted akik a stabil apit hiányolják, azok kernelpatcheket akarnak hozzáadni a kernelhez, vagy inkább 3rd party drvereket akarnak lefordítani? Megsúgom, az utóbbiból picit több van. Egyébként hogy hívod a driverfejlesztőknek nyújtott programozói interface-t ha nem api-nak?

--
Don't be an Ubuntard!

Nem és vannak akik azt akarják, hogy az legyen.

A Linuxban koncepció, hogy a driver a kernel része, nem pedig floppyról betöltendő valami, ami:

  • Opensource. A stabil driver API kétes minőségű, modellváltással sorsárahagyott bináris drivereket tömegét hozná (igen, a Linux<1% miatt)
  • "plug n play", nem kell driverre vadászni
  • Többé-kevésbé ellenőrzött minőségű, kihasználja a kernel keretrendszereit és a bevett eljárásokat
  • Mivel a kernel része, könnyen módosítható ha változik valami (pl. API, új platform támogatása), nem kell kismillió külső fejlesztőt kérlelni ami visszafogja a fejlődést

(saját vélemény)

A (nagyon) stabil driver API egyszerűen idegen az opensource-tól és káros is rá nézve. Akik ezt követelik azok vagy nem értik az opensource lényegét és azt, hogy nem egy új Windowst akarnak a Linusék csinálni, vagy egyszerűen trollok, akik ugyanazt a csontot rágják, a Linux hiányosságának feltüntetve azt, ami valójában az éltető eleme. Emiatt tényleg értelmetlen ez a szál és ha éppen nem unatkoznék laptoppal az ölemben várakozva valakire, egy betűt nem pazaroltam volna erre. :)

A vanilla-fán kívüli driverek egyetlen célja az kell(ene) hogy legyen, hogy bejussanak a mainlineba, nem pedig az, hogy végfelhasználók használják. A driver fejlesztője valamit rosszul csinál, ha nem így jár el, ami az ő hibája, nem máté!

(tribute to matula báti)

"nem értik az opensource lényegét"

Valaki ezt magyarázza már el, mert egy héten belül másodszor olvasom, de még egyszer se fejtette ki senki.

Egyébként a gond az, hogy mivel az api nem stabil, ezért egy cég a hw-éhez inkább nem is ad ki linuxos drivert (specifikációt meg maximum NDA alatt), hanem úgy van vele, hogy egy max. 2%-os piac elvesztése még nem csökkenti jelentősen a bevételeit. Majd egy hobbikóder megírja a drivert ha akarja, és ha szerencséje van, mire a hw elavul, a driver is stabil lesz.

--
Don't be an Ubuntard!

Ebben a kontextusban az opensource egyik fő célja, hogy mégtöbb opensource kód legyen, minél szélesebb ökoszisztéma. A stabil API ezen nem segít, sőt, inkább veszélyes. Ezen belül, a kernelnek nem célja az opensource 3rd party driverek támogatása sem, hogy miért, arról meg már írtam.

Amit mondassz, igaz. Ugyanakkor azt kell látni, hogy nem kell minden áron az a driver. A Linux minden típusú általános célú hardverből tud használni valamilyet már most.
A 99%-os desktop részesedéshez valóban kéne az, hogy a mindent támogasson, de a helyzet az, hogy a 99%-os "álom" közel sem annyira egységes akarat, mint ahogy azt képzelik, hogy azért az annyát is eladná Linus (maradjunk kernel kontextusban). Konkrétan, szerintem, őt teljesen hidegen haggya az aktuális desktop-penetráció.

Ezzel szemben az opensource ökoszisztéma szinte minden FOSS fejlesztőnek érdeke és le merném fogadni, hogy sokkal fontosabbra tennék, mint a nagy penetrációt (bár nem tudok efféle felmérésről). Ezért van az, hogy fityiszt tartanak a Linuxra éhes tömegek (lol) felé, hiszen a lényeg, az ökoszisztéma, az utóbbi években robbanásszerű növekedésnek indult. Semmi nem indokolja, hogy irányt változtassanak, az sem, ha a Mark Shuttleworth téden állva könyögörögne ezért (mellesleg nem teszi, az Ubuntu sem hugyozik szembe a széllel, bár neki valóban fontos lenne a nagyobb penetráció).

Többek közt ezért nincs stabil API. Igazából az opensource-mozgalom egy példa nélküli modell és szerintem még túl fiatal ahhoz, hogy megítéljük a sikerességét. Lehet, hogy dugába dől, mint a hippimozgalom, de az biztos, hogy annak semmi értelme nem lenne, hogy egy ekkora kört leírva visszatérjenek a kezdőpontra azzal, hogy a zárt forrásnak teret adva áttérjenek egy olyan modellre, ahol már sokan motoroznak, három körös előnyben.

Ez, amit leírtál, kb. a stable_api_nonsense.txt zanzásítva.

Sajnos ez a kernel marketing egyszerűen nem igaz. Töltsd le a legfrissebb kernelt, és próbálj egy működő MIPS Malta platformos kernelt gyártani így: make malta_defconfig

Nem fog menni, mert a pcnet32 driver, ami az alaplapi interfész ezen a platformon, nem lett valamelyik csoda-átíráskor frissítve, ezért kellemes kernel panicokat okoz. Kérdés, hogy ki ezért a hibáért a felelős a stable_api_nonsense.txt ideológia alapján, és hogyan lesz megjavítva. Szerintem az "akinek kell, az majd megjavítja" hozzáállás pont ellentétes azzal, hogy "az in-tree drivereket majd jól karbantartják a kernelfejlesztők".

Nem állítom, hogy egy Linux kernel kiterjedtségű és struktúrájú projektnél egy erős(ebb) központosítás / standardizálási folyamat egyszerű. Az sem igaz, hogy a Linux kernelben felelőtlen cowboy-kódolás folyik. Nem annyira látható, de létezik szervezeti hierarchia (alrendszer maintainerek), akik próbálják a "káoszt" kézben tartani.

De a helyzetet ideálisnak beállítani, és ideológiával megtámogatni önmagunk becsapása. Nagyon sok QA és menedzsment feladatot kéne megoldani, amit jelenleg a kernel fejlesztési folyamat nem képes, ezért letolják a felhasználókra (ezek a disztribútorok).

Ennek folyománya, hogy a Linus féle vanilla kernel releasek (mindegy, hogy milyen verziószámmal) nem alkalmasak éles felhasználásra, egy fejlesztői snapshot release-nek tekintendők, amik alkalmasak arra, hogy termékfejlesztésre szakosodott cégek / csapatok alapozzák rá a saját fejlesztéseiket.

Ez nem feltétlenül baj, de jobb lenne, ha ezt a kernel fejlesztők is elismernék, mert úgy lehetne előrébb lépni a folyamatok és a QA terén.

Üdv,
Gergely

Nincs az a fejleszési módszertan jelenleg, ami bugmentes szoftvert garantálna.

Egyébként ez itt offtopic. A QA helyzete független attól, hogy a kernelbe beépülő, de azon kívül fejlesztett modulokkal mennyi szívás van a kernel változásai miatt.

Mindenesetre érdekel, hogy mi a baj azzal, hogy a QA-t letolják pl a Redhatre, akiknek az ügyfelei fizetnek azért, hogy végezzék el azt? A hibajavítások visszakerülnek a fejlesztőkhöz, az ügyfél jó minőségű szoftvert kap, a fejlesztő pedig fejleszthet, nem kell zavaros bugreportokat válogatnia. Ezt a modellt épp Linus preferálja a 2.6 óta, fogalmam sincs honnan veszed azt, hogy a kernelfejlesztők szerint az edge kernel a legstabilabb kernel.
Az OSS nem arról szól, hogy más mindent megold helyetted, ingyen.

Tehát, konrétan: egy olyan szoftvernél, ahol nincs semmiféle jótállás, nincs (jogi értelemben) felelős sem. Egy harmadik féltől vehetsz supportot, akik pénzért kijavítják neked a hibát, aztán ideális esetben commitolják upstream (szerintem akár itt a hupon is találnál rá vállalkozót). Az OSS ereje, hogy meghaggya a választás szabadságát, azzal javíttatod ki akivel akarod, akár saját magad is megcsinálhatod vagy benyújtod a panaszt az eredeti fejlesztőnek és vársz amíg nem akad jobb dolga.

Ezzel szemben ott a zárt modell, ahol benyújthatod a panaszt, amire valamikor reagálnak, te pedig kivárod. AFAIK a zárt szoftverek licensze a legritkább esetben vállal garanciát a hibamentes működésért, illetve a hibák határidős javításáért. Én, személy szerint, nem látom a követendő példát ezen a területen.

A kód minősége -ami itt felmerülhet mint gondolat-, megint egy újabb témakör lenne.

Mindenesetre érdekel, hogy mi a baj azzal, hogy a QA-t letolják pl a Redhatre, akiknek az ügyfelei fizetnek azért, hogy végezzék el azt?

Az, h a RedHat-ra toljak a QA-t okes lepes, meg ha nem is erdekel senkit, h az o QA-juk eleg specifikus ismerven a profiljukat. Az mar nem teljesen okes, h mindenki masra is igy tekintenek.

---
pontscho / fresh!mindworkz

( 4fonya | 2011. 05. 24., k – 10:06 )

Most lenne alkalom hogy újragondolják és átírják az alapokat.

+1

.. más

Kilépve egy kicsit a kernel vonal mögül...

Amikor megkérdezem az ügyfelem, hogy a szolgáltatásával kiket is szeretne megcélozni, a válasz 80%-ban az, hogy mindenkit. Márpedig aki kicsit is dolgozott marketing / management vonalon az tudja, hogy mindenkit = senkit. Azzal, hogy mindenki igényeinek megfelelünk egy kicsit, az azt jelenti, hogy senkinek sem felelünk meg kielégítően. Akik szerver vonalon használják, nem mindig nézik jó szemmel a desktop usereknek szánt változtatásokat, a desktop usereknek meg még mindig nem elég jó a Linux, mint alternatíva ilyen / olyan okból.

Valami ilyesmit érzek én is azoknak az írásaiból, akik a kernel kapcsán sokmindent felvetnek.

Elvi szinten híve vagyok a rekoncepciónak, biztos, hogy egy rakás dolgot lehetne sokkal jobban implementálni második körben...de ha ezzel elszállna a project, és egy álomszerű, soha meg nem valósuló kutatás lenne...egyesek szerint már most is az az egész linux, mivel most se lehet befejezettnek nevezni desktop oldalról.

Igazából a szoftvervilág annyira új dolog, hogy "befejezettnek tekinteni" ezzel kapcsolatban bármit, még egy ideig nem lesz aktuális dolog. Azonban jó lenne biztosítani valamilyen átjárhatóságot, vagy állandóságot (API, ABI, stb) amibe megérné időt/pénzt fektetni.

Ma jelenleg egy Linuxra írt szoftvert supportálni nagyságrendekkel több munka, mint w*ndosos társát. Evidens, hogy kereskedelmi szoftver forrását nem fogom feltenni, hogy telepítse forrásból :) Hogyan készítsek olyan szoftvert és ahhoz telepítőt az r=1 usernek, hogy ne kelljen fenntartanom n+1 disztró n+1 verziószámát, hogy mindenre feltehesse a szoftverét.

Nem nehéz pedig telepítőt készíteni, ami az /opt-ba rakja a dolgokat. Plusz lehet írni a programot Java-ban vagy Mono-ban és akkor Windowson is használható lesz. Linuxon nyugodtan meg lehet hagyni a telepítő scriptet, oda nem kell semmilyen grafikus telepítő, úgyis ért hozzá, aki linuxot használ. Csak a lehetőség legyen meg.

--
http://sandor.czettner.hu
http://turaindex.hu

"úgyis ért hozzá, aki linuxot használ"
Na ezért nem jött még el a Linux desktop éve :) Pont az lenne a lényeg, hogy ne mélyen érteni hozzá...
Amúgy meg a mono/java telepítő nem oldja meg azt a problémát, hogy az egyik disztrón így nevezik a libet, a másikon úgy... vagy az egyiken ebben a csomagban van, a másikban amott... Aztán symlinkelheted "kézzel"... stb.. még sorolhatnám azokat, amikkel sokat szívtam...

( manfreed (nem ellenőrzött) | 2011. 05. 24., k – 11:49 )

Valamelyest jobb ötletnek tartanám, ha a 3.0 valamilyen szinten újragondolt, újraírt verzió lenne.
Biztos vagyok benne, hogy lehetne dolgokat másképp csinálni, és akkor jobb lenne, és abban is hogy iszonyú nagy munka lenne. Azért álmodozni jó.

A dátum szerinti verziózást jó ötletnek tartom.

( STP | 2011. 05. 24., k – 11:59 )

"Mivel ha hangok bíztatják arra, hogy valamit tegyen meg, akkor azokra figyelni szokott."
Gyanús volt eddig is ez a fiú! :)

"Vagyis a 3.0 után jöhetne a 3.1, a 3.2 után a 3.3... Ezzel múlttá válna, hogy a páratlanra végződő kernelverziók "unstable" verziók."
Tehát így már deklaráltan, a párosra végződők is lehetnek "unstable" verziók.

( Vladi | 2011. 05. 24., k – 17:37 )

Atyavilág. Ezt ugye a háziorvosával nem közölte? :DDD

Egyébként mi indokolja a verziószám váltást? Könnyebb követni, vagy technikai oka is van?

>>: sys-admin.hu :<<

( turul16 v | 2011. 05. 25., sze – 08:06 )

Valaki elolvasta a linkelet leveleket ?

3.x re valo atteres oka az lenne, hogy igy rovidebb lenne a kernel verzio szam.
Nem 2.6.44.11 lenne a 44. release 11. updateje, hanem 3.1.11.

Ez nem hangzik olyan nagy baromsagnak, mint a fenti osszeskuvesek.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.