Greg Kroah-Hartman: Linux 2.6.11.4

>> Írd meg a véleményed!

thx, en tovabbra is maradok az -ac-nal

congo wrote:
> Greg Kroah-Hartman kiadta a Linux kernel 2.6.11.4-as verzióját. Letölthető
> a kernel.org [0]-ról. Két biztonsági hibára tartalmaz javítást.
Mi ebben a hír?

az, h kiadta, vazze ;)

vmiklos wrote:
> az, h kiadta, vazze ;)
Akkor most kétnaponta fogunk ilyen "híreket" látni?
Kéne ebbe a portálmotorba egy csomagszűrő-szerű dolog. Bizonyos
"híreket" ki lehetne vele szűrni, másokat rate-limitelni lehetne,
egyebeket pedig vissza lehetne dobni a feladónak RST-vel. :)

Ugyan ott van minden, ahol eddig is volt. A 2.6.x.y ág pedig ott van Linus 'vanilla' 2.6.x kernelei mellett.

A kernel.org-rol beszelunk ugye?

Hja, bocs, semmiféle dokumentációban nem néztem utána, csak az eszemet használtam és a szememet nyitottam ki (;

Mit keresel tulajdonkeppen? Mert nem ertelek.

akkormar a debian biztonsagi figyelmezteteseket szurjuk ki elobb ;)

vmiklos wrote:
> akkormar a debian biztonsagi figyelmezteteseket szurjuk ki elobb ;)
Részemről OK :)

Ünnepek-hétvége alatt nem olvastam HUP-ot eléggé meglepett a 2.6.11.4-es kernel, csodálkoztam hogy tudtak ennyi mindent elb**ni :)

- GKH kernele == stabil kernel, http://www.kernel.org/pub/linux/kernel/v2.6/

- aj port afaik nincs

- ac honlapon

nemtom mi nem vilagos meg :)

Treszkai László wrote:
> Ünnepek-hétvége alatt nem olvastam HUP-ot eléggé meglepett a 2.6.11.4-es
> kernel, csodálkoztam hogy tudtak ennyi mindent elb**ni :)
Akkor még nem olvastál el mindent :)
Ez nem olyan, mint a .11-DONTUSE. Egész egyszerűen naponta kiadnak egy
kernelt azokkal a változásokkal, amelyeket Greg Kernel Hacker jónak lát.

Eddig is ugyanennyire el volt baszva a kernel, csak kéthavonta adták ki
a javításokat új verziószámmal, most ugyanez megvan két nap alatt.

Kicsit olvass ennek utana.

Ebben az az erdekes, hogy eddig pont a felhasznalok sirtak, hogy miert nincs gyors reagalas a biztonsagi hibakra. Most, hogy van, most ez a baj?

Latom, hogy remenytelen vagy. Mintha par nappal ezelott az irc-n elmagyaraztam volna, de ugy tunik teljesen felesleges volt.

Erdekes, ha en beirom, hogy www.kernel.org (es nem www.linux.org, amivel te probalkozol), akkor latom hogy mi az abra. Ugyanis oda ki van irva minden, amit erdemes tudni. Aki ennel tobbet akar, annak LKML-t kell olvasni. Ennek ellenere, ha tovabbra is bizonytalan vagy, szivesen osszefoglalom neked megegyszer.

Micskó Gábor wrote:
> Ebben az az erdekes, hogy eddig pont a felhasznalok sirtak, hogy miert
> nincs gyors reagalas a biztonsagi hibakra. Most, hogy van, most ez a baj?
Nem tudom. Nekem nem a kiadással van a bajom, hanem a módjával.

Nem értem miért kell 2 kB-os változtatásokért 75 MB-ot kitolni minden
mirrorra.

Inkább rá kéne szoktatni a usereket, hogy töltsék le CVS-sel, vagy
akármivel és csak a diffet. Ez nekik is könnyebb lenne...

Összefoglalva: felesleges időt, sávszélességet vesz el mindenkitől.

ezen mar 1x elvitatkoztunk, most minden hirnel kezdjuk elolrol? ;)

vmiklos wrote:
> ezen mar 1x elvitatkoztunk, most minden hirnel kezdjuk elolrol? ;)
Úgy tűnik kiégett az agyam helyén lévő flash. Nem elég, hogy eddig is
használhatatlanul lassú volt, most már adatot is veszt :-)

Nem _kell_ tudnod. Ahogy azt sem, hogy melyik az épp aktuális
kernelverzió. Használd a disztribúcióbeli kernelt, akkor elég, ha a
disztribúció készítői olvassák az LKML-t. Te saját cuccot akarsz
magadnak, akkor viszont elvárható, hogy utánaolvass.

--
--- Friczy ---
'Death is not a bug, it's a feature'

Jólvan, közben rájöttem :)

varj. unofficial stuffot ne keress a kernel.orgon. erted, mi is csinalunk -fw kernelfat, te is csinalhatsz olyat, amit jolesik, de nyilvan nem hostol mindent a kernel.org

ps: amit a cimlapon nem latsz, azt ne is keresd ott

> Bocs, de most Windowst használunk, vagy Linuxot? Szerintem azért nem kéne
> ennyire elhatárolódni a régi felfogástról, egyébként is egy rendezettebb
> kialakítás előnyösebb nekik is, főképp ha minden össze van foglalva.

Bocs, de windows-user vagy, vagy Linux-user, aki képes utánaolvasni
dolgoknak olyan forrásból, ami van? A nekik alatt meg nem tudom, kit
értesz. A kernelfejlesztők saját maguk feltehetőleg képben vannak így
is, ami meg nem nekik szól, az a főoldalról elérhető.

--
--- Friczy ---
'Death is not a bug, it's a feature'

Szerintem most ijedtek meg a kernel.orgon igazán. Ezek után biztos
megírják inkább ők :DDD

Hallottal mar az rsyncrol? Ajanlom figyelmedbe.

Masreszt nem kotelezo a kernel archiveot mirrorozni. Ha meg mirrorozza valaki, akkor ne sirjon.

vmiklos wrote:
> akkormar a debian biztonsagi figyelmezteteseket szurjuk ki elobb ;)

olvasd newsgw-ng-n a hupot, ott mar drewie megcsinalta, hogy a dsa-k nem
jelennek meg. eloszor azt hittem bug, de rajottem, hogy ez egy aldasos
feature... :-)

Egen... de ha már a kernel.org-on való eligazodás is gondot okoz... (;

pozsy wrote:
> Hallottal mar az rsyncrol? Ajanlom figyelmedbe.
Az ötlet jó lenne, de a megvalósítás sajnos rossz. Zabálja az
erőforrásokat. De ha ilyen nagy mellénnyel ajánlod, biztosan te is jól
tudod.

De ha már említetted, megpróbáltam a kedvedért:

bra@japan[/tmp/kernel]$ rsync -va --progress --stats
ftp.kfki.hu::ftp/linux/ftp.kernel.org/pub/linux/kernel/v2.6/linux-2.6.11.4.tar.bz2
linux-2.6.11.tar.bz2

Welcome to the rsync service at
ftp.kfki.hu

Please report any problem to ftpadm@ftp.kfki.hu

receiving file list ...
1 file to consider
linux-2.6.11.tar.bz2
37089740 100% 3.66MB/s 0:00:09 (1, 100.0% of 1)

Number of files: 1
Number of files transferred: 1
Total file size: 37089740 bytes
Total transferred file size: 37089740 bytes
Literal data: 37089740 bytes
Matched data: 0 bytes
File list size: 57
Total bytes sent: 36685
Total bytes received: 37094515

sent 36685 bytes received 37094515 bytes 2560772.41 bytes/sec
total size is 37089740 speedup is 1.00

Neked más rsynced van, vagy esetleg power-rsync-user vagy és mindenféle
trükkös paraméterrel, blokkméret-állítással, stb. nagyobb számot tudsz
varázsolni a "matched data" mögé?

Hogy megértsd, hogy miért pampogok, rávilágítanék, hogy a két 35 MB-os
fájl között egy 15 kB-os unified diff a különbség, amely egyébként 74
(!) sornyi változtatást takar.

Namost ezért a 74 sornyi változtatásért Great Kernel Hacker barátunk
teleszemeteli a világot több mint 300 MB-tal.

Lehet, hogy bennem van a hiba, de engem ez a "nemtörődömség" (úgyis van
hely bőven) elborzaszt.
Az is, hogy ma egy shell elindításához annyi memória kell, amennyiben
pár évvel ezelőtt egy Amiga 500-on már ray tracing programokat
futtathattál, komplett OS-sel, mindennel.

A különbség a shell és GKH műve között az, hogy míg a shell kisebb
memóriafogyasztásához elég sok munka kell (libc csökkentés, stb.), addig
ezt az egészet egyszerűbben is meg lehetne oldani.

Remélem valaki majd arra is rájön, hogy az így kiadott "stable"
kernelnél célszerű lenne visszaportolni a hibajavításokat a következő
"stable" verzióból, így a 2.6.11.158-as kernel bejelentéséről is
olvashatunk majd hírt... Várjunk csak... (átlag 3 naponta jelenik meg
egy ilyen kernel) 474 nap múlva! És ez csak 11 GB-ot foglal, de ez nem
gond, mert a hely ingyen van.

Abbahagytam. :)

Persze ez csak FUD :-)

Es a DSA-k elni fognak, mint a Java Mikulas!!!!111

Micskó Gábor wrote:
> Persze ez csak FUD :-)

Ehh ezt is megeltuk, hogy en keltek FUD-ot. :-D

> Es a DSA-k elni fognak, mint a Java Mikulas!!!!111

Ha mondjuk olyan gyakorisaggal jelennenek meg DSA-k, mint a Java
Mikulas, akkor ki is egyeznek vele... =) [evente, egyszer, de akkor husz
napon keresztul :-)]

Mihály Norbert wrote:
> Mit gondolsz miért pampogok kicsivcel lejjebb, hogy szerintem is tiszta
> káosz az egész? :)
Én a felesleges helypazarlásról beszéltem, nem a fájlok elrendezéséről.

Nem, te nem ezért pampogsz. Te azért pampogsz, mert nem látod meg azt, ami ott van orrod előtt, bra pedig azért pampog mert 2.6.x.y és 2.6.x.z között _nagyon_ kis eltérés van, és ehhez képest baromi sok helyet foglal...

Arra jó... De ha valaki egy ekkora akadályt képtelen leküzdeni, akkor nem hinném, h az valaha is képes lenne kernelt fejleszteni...

Mihály Norbert wrote:
> Én szeretem tisztán tudni dolgaim, számomra, és mások számára is könnyedén
> átláthatóvá tenni (najó, nem mindenhol, de ahol nem, ott pont az a cél).

A zseni atlat a kaoszon... ;-) (r)(c)

In article <42.39600@c.hup.hu>, Nagy Attila wrote:
> Hogy megértsd, hogy miért pampogok, rávilágítanék, hogy a két 35 MB-os
> fájl között egy 15 kB-os unified diff a különbség, amely egyébként 74
> (!) sornyi változtatást takar.

Woahh, en nagyon egyetertek veled megint, mindenben :) Don't panic, gyorsan
abbahagyom mielott miattam utalnak meg tegedis...

--
Bérczi Gábor
/Gabu/

Volt rajtad kívül valakinek problémája, h hol van a 2.6.x.y? Nem? Nahát... (;

Én is. És nyugodt lehetsz, azok is tudják, akik azt oda azért tették, amit ahova és amiért.

"Ha a kacsa nem tud úszni, nem a víz a hülye." (c)

Greg Kernel Hacker

ROTFL :DD

Csatlakozom, teljes mértékben. Aki nem hiszi el, hogy lehet tömören is dolgozni, nézzen meg egy-két 4k intrót, és csodálkozzon.

Természetesen ez a kompaktság-fejlesztési ráfordítás-továbbfejleszthetőség háromszögnek az egyik csücske, de azért az már mégis túlzás, hogy (ld. fentebb), szóval egyetértek bra-val :). Le a gigalomániával, mielőtt még a floppykábelre is hűtőventilátort kell szerelni!

lol, ezek utan nem csodalom, h neked valami nem tiszta.

Friczy wrote:
> Nem _kell_ tudnod. Ahogy azt sem, hogy melyik az épp aktuális
> kernelverzió. Használd a disztribúcióbeli kernelt, akkor elég, ha a
> disztribúció készítői olvassák az LKML-t. Te saját cuccot akarsz
> magadnak, akkor viszont elvárható, hogy utánaolvass.

En, mint az egyik disztrib egyik developere nagyjabol tudom, milyen munkak
vannak a hatterben...
Egyaltalan nem atlathato a rendszer. A sokfele "fat" kellene megszuntetni, mert
egy ido utan teljesen atlathatatlan lesz... Elismerem pl. hogy Alan jol dolgozik
es hasznos patch -eket csinal, amik joreszt stabilitast novelnek, de ezt talan
nem kulon faba kellene megcsinalnia, hanem visszaforgatni a "stabil" kernelbe.
Amugy jo az, ha van egy vezeto fejleszto, de az szerintem hatraltatja a munkat
es fuggove teszi a fejlesztoket, ha _csak_ Linus olvaszthatja be a hivatalos
faba a patch -eket... Erre szerintem Linus altal megjelolt, adott teruletekert
felelos emberek tokeletesen alkalmasak lennenek, ezaltal jelentosen lecsokkenne
az 1 emberre eso munka valamint egy patch bekerulesi/elvetesi ideje is... A
nemreg kidolgozott security modszer nem lenne rossz alap, csak kicsit tovabb
kellene fejleszteni...


IroNiQ
--
Member of Frugalware Developer Team
Web: http://www.ironiq.hu
LinuxCounter: #331532