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

 ( trey | 2011. május 23., hétfő - 21:39 )

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.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Linus valaszat olvasva Ingo felvetesere, egy kicsit elszomorodtam :(

--
|8]

"There's also the timing issue - since we no longer do version numbers
based on features, but based on time"

En ennek hallatara szomorodok el nem kicsit... Akkor minek a verzio szam...? :(

Több értelme lenne átállni időalapú számozásra, tekintve hogy évente több stabil kiadásuk is van - a .39 lehetett volna a 11.05, például :).

version=`date +%s`


suckIT szopás minden nap! Perl script 11 millió forintért

Aztan majd jonnek a kodnevek... Nut, Peanut, Coconut...
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Bikeshed.

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.)

+1

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]

É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 --

Kétlem, hogy komolyabb koncepcióbeli változásokat eszközölnének. Egyszerűen csak folytatják a munkát, más verziószámmal.

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

mivel linus sajat bevallasa szerint is (lasd fentebb linkelt level) hasrautesszeruen verziozgatja es nyilvanitja 'stabilnak' a hobbyprojektjet, ezert nyilvan csak marketing erteke lesz ;)

--
NetBSD - Simplicity is prerequisite for reliability

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

Legyen a verziószám a dátum, utána pedig egy wc -l a diffre a korábbi verzióhoz képest.


suckIT szopás minden nap! Perl script 11 millió forintért

wc előtt meg még egy grep ^+

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.

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.)

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

:)

Vagy csak nem ismeri az ssh-t.

--
Don't be an Ubuntard!

Vagy ismeri, csak a 3g mobilnetes cucca nem működik linux-szal :D

Es nem ismeri a puttyot. Pedig az mintha GPL-es termek lenne.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Linus Windows-on nyomatja szerinted putty-ot?

Bár nem lenne meglepő Linustól, semmi sem az tőle...

Nem tudtam, hogy linuxos is van belőle. Legalábbis én a Windows verziót is utálom, de ha nincs más, hát azt kell használni.

De hogy Linux alatt mi értelme, amikor tök jó terminálok és ssh is van, nem tudom megérteni.

Furcsa.

200+ vas eseten a sessionokat taroltad benne; innettol fejbol kellene ezeket...
Win->linux valtasnal nagyon is sok ertelme van (par kollegam atelte).

~/.ssh/config

---------------------------------------------------------------------------------------
Unix is simple. It just takes a genius to understand its simplicity. — Dennis Ritchie

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ár, hogy nem fejlesztik:

The latest version is beta 0.60.
2007-04-29 PuTTY 0.60 is released

nem egy hyperaktiv projekt, de azert ennyire nem doglott be: http://svn.tartarus.org/sgt/putty/?sortby=date#dirlist

en mindig a snapshotot rakom fel

--
NetBSD - Simplicity is prerequisite for reliability

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.

Nekem az jutott eszembe, hogy egy régi P500-as laptopon megy neki egyedül a Linux és fél váltani, mert megint 8 év kell, hogy minden hardver támogatva legyen.

:)

hasznaltal mar gitet? ahahahah

--
NetBSD - Simplicity is prerequisite for reliability

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

Lassan kezd ő is meghülyülni, mint RMS.

Én is ettől tartok. (De annak ellenére, hogy ki merem mondani, nem örülök neki.) Sajnos, úgy tűnik, lassan ideje lesz oprendszert váltani. Nincs más út, mint a Windows :-(

Azon túl, hogy a verziószámozás kérdésében most van egy kis WTF, mi más utal az őrületre? Komolyan érdekelne.

Iiigen... 3.1->95->98-XP->Vista->7 van olyan konzisztens mint a 2.6->(2.8|3.0), valoban. Es sokkal kevesbe utal elmebajra, igen, igen...

--
|8]

http://www.nirmaltv.com/2009/08/17/windows-os-version-numbers/
Olyan ez, mint a kedvencednél a nutty narwhore, vagy a pootattoo, vagy a makefile-ban beállított ugyanez.


suckIT szopás minden nap! Perl script 11 millió forintért

Igen. Pont kb ezt irtam en is, csak a masik oldalrol megkozelitve. Legkozelebb majd megfelelo pseudo-taget hasznalok, hogy megertsd. Ennek hianyaert utolag is elnezest!

--
|8]

Én továbbra se értem, hogy egy oprendszer fantázianevét hogyan próbálod összehasonlítani a kernel verziószámozásával, de trollkodásnak jó... ;)

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]

Már csak a 2k8 server hiányzik, ahol is az R2-nél szinte már-már megint 2 út halad :P
----------------------------
Weblap, Tárhely, Domain

???

Na azért a wint ne keverjük ide. Annyira azért nem rossz a helyzet, hogy arra a xarra kelljen fanyalodnom. Attól mert Linus bolondul megfele, legalábbis a hangok egyre erősödnek a fejében, azért nekem még elég jó a Linux is. :) És azért még van alternatíva.

Lassan gondolatolvasó lesz. :-)

Delirium tremens, jönnek az egerek is nemsokára.

subscribe

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

Ez a kernel fejlesztés egy káosz.

Addig jó.

Ezt fejtsd ki :)

Arra várhatsz a HUP legnagyobb trolljától.

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.

akkor akár a changelog md5sumja is lehet a verziójelölés, pontosan ugyanakkora gyakorlati haszna lenne, mint a jelenleginek

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

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.

Talán akkor fejezik be a fejlesztést ha elérik a nullát?

Vagy esetleg ismerik a negatív számokat is?

É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.

pl 1105.3-ck2?

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

> Én jobban örülnék egy stabil API -nak.

Itt van néhány API változás, mi ezekkel a bajod?

http://man7.org/tlpi/api_changes/index.html

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!

> Múltkor csak a poén kedvéért lefordítottam egy kernel modult

Kiestél a témából, csak arról van szó, amiről a könyv szól: http://man7.org/tlpi/

Csak a tisztazas kedveert, ez volt a kerdes. A te temad egy ettol tobbe-kevesbe fuggetlen tema.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

> Csak a tisztazas kedveert, ez [stabil API] volt a kerdes.

Csak a tisztázás kedvéért, ha valaki "API"-t ír, akkor én API-t fogok ebből kiolvasni, nem mást.

É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!

> És szerinted akik a stabil apit hiányolják,

Tévednek, az API elegendően stabil.

> Egyébként hogy hívod a driverfejlesztőknek nyújtott programozói interface-t ha nem api-nak?

Driver Programming Interface :-)))

Fránya GKH is stable API-nak hívja a nonsense agymenésében. :(

Megnéztem: "API" betűcsoport nincs a szövegben.

Jogos; a "rapid"-ban mégiscsak előfordul az "API" :-)))

Keresd meg nyugodtan a szövegben, GKH hogy nevezi ...

Csináld nyugodtan a hülyét, engem szórakoztatsz. :)

Igazabol en is jol szorakozom ujabban az ilyesmin. :)

---
pontscho / fresh!mindworkz

baszki, hogy mikről maradok én le


"no video codec le a win32vel", de "Gentoohoz lehet meg tul fiatal vagy"

Alkalmazas -e egy (kernel szintu) driver ?


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

sajnos nem értem hogy jön ez ide

Ez egy egyszeru eldontendo kerdes.
Nekem segitene ertelmezni az egesz ertelmetlennek latszo szallat.


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Ez esetben zambojimiz apukádtól kérdezd. ;)

Ha szerinte elegendően stabil, akkor vagy trollkodik (nem lenne meglepő tőle), vagy keveri az ABI-val, amire talán rálehetne fogni, hogy elegendően stabil.

Kimaradt a szövegedből hogy miről beszélsz. Mi az ami szerintem elegendően stabil? Mit keverek az ABI-val? Nevezd meg, csak hogy kiderüljön végre.

-

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)

szép álom

"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.

Konkrétan, szerintem, őt teljesen hidegen haggya az aktuális desktop-penetráció.

Jahahah, emlékszünk még, hogy három éve majdnem kinyírta az asszony, mert egy vacak YouTube-ot se tudott működésre bírni neki Linux alatt... :))

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.

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

az elvi bizonyítás nem ilyen?

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

Na igen, átszerkesztettem a hozzászólást és beszúrtam a "komplex" szót a "szoftver" elé, csak már menteni nem volt időm.. :)

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.

> egy olyan szoftvernél, ahol nincs semmiféle jótállás, nincs (jogi értelemben) felelős sem.

Ellenben az olyan szoftverrel, ahol van mindenféle jótállás? :-)))

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

> Az mar nem teljesen okes, h mindenki masra is igy tekintenek.

Szégyen. Dagonyáznak a szakbarbárkodásban, még a man lapok honosítását is mással végeztetik.

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

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

Szerintem jobb hogy folyamatosan "újragondolják és átírják az alapokat", minthogy X-évente ...

Az ötlet nem rossz, csak kérdés, hogy így hány év múlva lenne belőle kiadás.

+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.

Volt valami autopackager, vagy mifene. Olyasmi felületet adott, mintha egy Windows-on installálna az ember. Úgy tudom, nem folytatják, hanem alternatívákat kínálnak maguk helyett.

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...

Amint olyan lesz a linux, amit mindenki tud használni, ideje lesz áttérnem BSD-re. :) Már az ubuntut sem szeretem, mert magától akar megoldani mindent, nekem meg használhatatlan.

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

+500. van olyan állatfaj, amely bármilyen rendszert sokkal nehezebbre cserél, csak a KISS principle (és semmi más) miatt.

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

64 bites uid/gid mindenhova!!


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

A Linux kernel alapjainak melyik részével vagy elégedetlen? Egyáltalán mik a kernel alapjai?

Üdv,
Gergely

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.

"Ha vannak akik jól csinálnak dolgokat, és vannak akik rosszul csinálnak dolgokat, akkor ne azok a dolgok legyenek mindig, amik a nem jól csinált dolgok..." :)

"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.

Ja, gyanús alak. :)

S mi van akkor ha ez hang súgta annó, hogy csináljon már egy kernelt és adja közre. Ha így volt akkor biz örülök hogy susogott neki.

+1

milyen jó is lenne ha nem lenne más választás, csak mswin pl. meg nem lennének alternatív szoftverek. legalább adhatnák a mostani cuccaikat ennek sokszorosáért :)

Megnézném milyen lenne a világ Linux nélkül.

hurd? kolibriOS?

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

linux nélkül is_, meg más egyéb alternatív szoftver nélkül is_, én is megnézném, habár csak youtube videon maximum.

Hát volt még pár alternatíva (pl.: BeOS). De tény, hogy a Linux a legéletképesebb az összes alternatívából.

Igazabol nem, csak a tobbiek egy picit kesobb kezdtek. Ha Linus nem irja meg a Linux-ot, akkor valamelyik BSD fork fejlodott volna fel valszinuleg.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

de lenne

--
NetBSD - Simplicity is prerequisite for reliability

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 :<<

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.

Nincs mese megérett! :D