Linus Torvalds: Linux 2.6.26-rc1

Kernel

Bezárult a "merge window", így Linus kiadta a 2.6.26-os kernel első kiadásra jelölt verzióját. Mint írta, ez a beolvasztási időablak egy kissé rögös volt abban az értelemben, hogy elég sok vitát generált, de személy szerint úgy érzi, hogy - legalábbis technikai szemszögből - kevesebb "ijesztő" cucc került bele ebbe a pre kernelbe, mint ahogy az mostanság szokványos volt. A maga 7 500 körüli commit-jával ez a ciklus kevesebb változást hoz majd, mint az előző néhány. A változások többsége infrastruktúrális, így nyilvánvalóan kevesebb új szolgáltatást hoz majd a 2.6.26. A jelentősebb változások közül az LWN az x86 memóriakezelő kódjában megjelenő PAT támogatást, a realtime group scheduler körül végzett munkát, a read-only bind mounts-t, a kgdb beolvasztást és egy rakás új driver megjelenését emelte ki. A bejelentés elolvasható itt.

Hmm..lehet túl "kapzsi" vagyok, de én isdn, és stb-ket, már nem nagyon fejleszteném.. tényleg van jövője az ilyen dolgoknak? Vagyis..megéri egyáltalán még fejleszteni? Én alapból kikapom menuconfig-ból mikor kernelt forgatok mert egyszerűen hasztalannak tartom a mai korban már..

Vanillában is benne van a kód, csak van egy ellenőrzés ami letiltja. Ha működött neked az, akkor csak szedd ki a drivers/net/wireless/rt2x00/rt2x00mac.c fileban a 


if (conf->type == IEEE80211_IF_TYPE_IBSS ||
    conf->type == IEEE80211_IF_TYPE_AP) {
        ERROR(rt2x00dev,
              "rt2x00 does not support Adhoc or Master mode");
        return -EOPNOTSUPP;
}

feltételeléből az IBSS ellenőrzést. De mivel nem beacon-öl rendesen a driver, így tudtommal legfeljebb másmilyen kártyákkal lehet együttműködésre bírni.

Dokumentáció tudtommal csak néhány fejlesztőnek jutott, NDA aláírása után, de ha foglalkozni akarsz vele, úgy rémlik a legacy driverekben volt ad-hoc támogatás.

csak egy lehetséges ok :P
de szvsz még ma is fejlesztik az különböző isdn eszközöket és még jópár helyen használják, így egyhamar nem is fog eltünni a kernelbpl, max akkor, ha már nem lesz karbantartva a kód, de akkor is csak egy egész torúra után. [off]ez van most a v850-es arch-val is, Adrien Bunk ki akarja vágni, mivel már 2.6.19-es kernel óta nincs karbantartva és le sem lehet forsítani (állítólag), de Linus még nem vágta ki[/off]

debian gnu/linux @ linux-2.6.22.22-op1-rc1 | patch
info

( evone | 2008. 05. 04., v – 17:05 )

minden heten uj kernel lesz bejelentve?

"stabil" korszerű és bugfixelt, ez így paradoxon lesz mindig...
lást freebsd, az stabil, de nem támogat minden új hw-t, szóval kompromisszumokat kell kötni (sajnos), ha a hw gyártója nem támogatja a kernel(eket) stabil driverral

debian gnu/linux @ linux-2.6.22.22-op1-rc1 | patch
info

> Linus pedig (sajnos) hagyja.

Nem látom a fork hegyeket, akik megpróbálnák máshogy csinálni. Ebből arra következtetek, hogy ...

> minden hw, és eszement szoftver fejlesztő ezen a játszótéren éli ki a kreativitási őrületét.

Mondj 1db "hw, és eszement szoftver fejlesztő"-t, aki "ezen a játszótéren éli ki a kreativitási őrületét".

Köszi.

"Nem látom a fork hegyeket, akik megpróbálnák máshogy csinálni. Ebből arra következtetek, hogy ..."

Te is tudod, hogy komoly fork csak minimum 3-5 évente keletkezhetne, ami mögé odaállnának a nagyok is.

"Mondj 1db "hw, és eszement szoftver fejlesztő"-t, aki "ezen a játszótéren éli ki a kreativitási őrületét".

Szerintem ~1 éven belül 5 új kernel verziót kiadni eszementség.
2.6.21 ... 2.6.26

Elarulom, hogy nagyok azok akiknak a jatszotere a legujabb vanilla kernel.
Nagyoknak pont ez a biznisz..

Linux a leggyorsabban fejlodo kernel(+driver) egyutess. Ennek klucs eleme az "adj ki gyakran".
Mission critical helyen nyilvan kevesen alaklmazzak a legujabb kernelt. Arra ott vannak stablizacios agak, vagy a gyartok altal szalitott kernelek.

"Mission critical helyen nyilvan kevesen alaklmazzak a legujabb kernelt. Arra ott vannak stablizacios agak, vagy a gyartok altal szalitott kernelek."

Erre valami info? Pont, hogy ott nem alkalmaznék kiteszteletlen (bocs, de ez az rc-zés ez vicc) cuccot, ahol meg nem állhat a rendszer.

nyilt forraskodu szoftver!=kesz megoldas

Ha neked egy stabil, supportalt kernelre van szukseged tobb szaz ceg varja a par ezer dollarodat, osszegtol fuggo SLA-val.

Ingyen nyilvan senki se fog supportalni, mert ahhoz fenn kell tartani egy ejjel nappal mukodo bugfix csapatot, ugyfelszolgalatot, tanacsadokat, mernokoket stb.

Tegyuk fel, hogy lenne ilyen stabilizacios ag.. ott mi garantalna, hogy egy adott security fix bekerul adott idon belul? Az eg vilagon semmi, onkentes fejleszto ha eppen raer, akkor beteszi, de ha inkabb a baratnojevel megy el bulizni, akkor nem. Gondolom mission critical helyre nem ilyen szintu biztonsagot szeretnel, hanem olyat, amit szerzodes rogzit (azert pedig fizetni kell..)

Az persze igaz, hogy a kernelt ma mar nem onkentesek fejlesztik joreszt, azonban ha egy idoben van mondjuk 10 biztonsagi hiba, es teged abbol csak az egyik erint, akkor meg mindig semmi nem garantalja, hogy egy stabil ag eseten nem az elso 9-el foglalkoznak eloszor, es csak utana a teged erinto egy hibaval. Ez pedig konnyen megtortenhet, hiszen a ceges fejlesztok nyilvan azzal fognak eloszor foglalkozni, amiert az ugyfelek fizetnek, es csak azutan azzal, amit a kozossegi userek szeretnenek.

Kivallo, akkor holnap huzzuk ki az osszes linux alapu emb gepet, szervert, desktopot energiacsokketes celjabol. Szegenyes lenne hirtelen az internet. Meg jo, hogy ekkora darab fost hasznalnak az emberek.
2.4 koraban volt sajat fbsd mivel jobb volt a halozati teljesitmenye. A 2.6 szeria ugy elment emellet, mint a huzat, ki is lett dobva a fbsd mint a huzat. Nem sajat reszen van, hasznalom, adminolom, nem tolt el boldogsaggal.

Nem tudom, nem végeztem ezirányú kutatásokat és nem is valószínű, hogy ki lehetne deríteni az igazságot.
Azt ugye tudjuk, hogy a BSD-k nem profitálnak túlságosan a linuxos driverekből, hiszen át nem tudják azokat emelni (ez csak fordítva működik).
Esetleg belenézhetnek, ha már dokumentációt nem kaptak, ennyi haszna kétségtelenül van.
Lehet még szerepe abban, hogy mivel a Linux terjed, terjed vele együtt minden más nyílt forrású megoldás. Azonban én úgy látom, hogy a gyártóknak épp elég fájdalmat jelent a Linux naponta változó környezetét követni, illetve attól, hogy Linuxot használ mindenki, még nem fog egy gyártó mondjuk FreeBSD drivert fejleszteni.
Ezt tehát inkább kilőném.

Az én válaszom tehát: pici (és hangsúlyoznám ezt a szót, szerintem jót választottál) szerepe biztosan van, de én inkább arra tippelnék, hogy a FreeBSD-s commit logokban egyre inkább szaporodó "sponsored by" soroknak nagyobb hatása van erre. Azaz a FreeBSD is terjed, egyre több helyen használják, csak ennek kevesebb marketingje és így visszhangja van, nem olyan látványos, mint a Linux esetében.

Magyarországon -és a userek szempontjából- valószínűleg igazad van. De egy fejlesztő nem azért mondja a FreeBSD 7-STABLE-re, hogy STABLE, mert az garantáltan nem fog összedőlni, hanem azért, mert abba már nem tesz olyan dolgokat, amelyek alapjaiban felforgatnák a rendszert, annak az útja többé-kevésbé kiszámítható, ami ma működik benne, az holnap is fog, stb.

Azt a stabilitást, amire te gondolsz szerintem (működési) megbízhatóságnak -reliability- hívják, és valamilyen szinten valóban következik a stabilitásból, hiszen ha nem pakolsz bele naponta 28M sornyi diffet, csak kisebb, átgondolt, tesztelt, bizonyított megoldásokat, nyilván kisebb az esély arra, hogy hibázz.

Szóval ez tényleg szvsz kategória, szerinted így van, de valójában (szerintem :) nem.

Nem értem, hogy mi az urban legend. Az, hogy a gyártóknak ez sok munka? (azért, mert ha adnak doksit, eszközt, valaki megírja?)

Ki fizetné vajon ezeket a driverírókat akkor, ha mondjuk egy varázsütésre holnap minden gyártó adna doksit, eszközt? Nem lehet, hogy ez kis méretben működik, de nagyban már gondok lennének?

( honorshark | 2008. 05. 04., v – 17:23 )

Hmm..én azért csinálnék egy olyan rendszert amivel egy megadott számonként (mint ahogy a 2.6.22-y is készül) freeze lenne a kernelnél, és csak bugfixelnék. Akkor végtére is a distro dev általá készített kernel team is dolgozhatna azokon a hosszú távú kerneleken, és így tovább. (Itt nem valami vészes időre gondolok, csak egy picit hosszabbra mint most...)

Tökéletes szoftver ugyebár nincs ;) Mindenesetre én is elégedett vagyok a Linux-szal. (van egy Debianos otthoni szerverem meg egy desktop Gentoo-m). A nagygépemen is az lenne, ha nVidia -m lenne.

http://gyuszk.homelinux.org

-- There is never time to do it right, but always time to do it over.