Megszűnik a -ck patchset

Kernel

2.6.22-ck1 will be the last -ck ever - olvashatjuk Con Kolivas weblapján. A hacker sajnos abbahagyja népszerű, teljesítménynövelő patch összeállításának fejlesztését. Az oldalon semmilyen okot nem közöl, de a CK Wikiben olvashatunk pár tippet.

( mindegy v | 2007. 06. 22., p – 11:04 )

Én olvastam a levlistát, gondoltam is, hogy be kéne küldeni hírként...

A lényeg:
Kolivas belefáradt, hogy hiába dolgozik, nem kerülnek be a jó foltjai a hivatalos kernelbe. Egyrészt Andrew Morton nem fogadja be a swap prefetcht és végül nem az ő új SD (Staircase-Deadline) nevű CPU-ütemezőjét fogják beolvasztani, hanem az ő ötletei alapján Molnár Ingo által írt CFS-t. Ennek kapcsán kicsit érzelmek által dominált vita alakult ki, mert Con és több támogatója meg vannak győződve arról, hogy összehasonlítva a kettőt az SD jobban teljesít, mint a CFS.
Én csak az SD-t próbáltam, így nem tudok nyilatkozni.

Viszont régóta használom a ck-t és nagyon szerettem, sokkal jobb volt a használhatósága a gépemnek, mint a vanilla kernellel.

Kolivas belefáradt, hogy hiába dolgozik, nem kerülnek be a jó foltjai a hivatalos kernelbe

Lám-lám, itt is látszik, hogy a Linux esetén már mennyire nem érvényesül az a híres bazár modell...

nem az ő új SD (Staircase-Deadline) nevű CPU-ütemezőjét fogják beolvasztani, hanem az ő ötletei alapján Molnár Ingo által írt CFS-t.

Nahát, vajon miért? Talán mert Ingo nem "szabadúszó", hanem RedHat alkalmazásban áll és így érdekek sérülnének különben? :)

Kísérteties hasonlóságot látok itt azzal, hogy a PaX sem került be, majd később az Ingo sokkal gyengébb utánzata (ExecShield) lett beolvasztva a RedHat-nél is, amelyik tele volt (és van ;) security problémákkal, pedig egy biztonságot fokozó patchnek kellene lennie... (Ennek ellenére inkább csak egy hamis biztonságérzetet fokozó megoldás. ;))

> eax, hunger?

eax nem magyarázott (ebben a témakörben) semmit. Hunger "kísérteties hasonlóság látása" elfogadható "magyarázat"-ként.

A kérdésem az volt, hogy "Kik magyaráznak hiába? (Bece)neveket plíz."

A többesszám, miszerint téged is beleértve _egynél_többen_ magyaráznak, meg az hogy ezek a meg nem nevezett személyek _hiába_ magyaráznak, az továbbra se stimmel.

Majdnem a hozzászólásom végére írtam, hogy: "Azt meg hogy miért nem lehet érthetően fogalmazni, a fene se érti. Ezek itt ilyen buzik." Illett volna a hozzászólásod végéhez.

De aztán meggondoltam magam.

--
hup.user.js

Ez mind egy és ugyanaz a csodálatos személyiség :-)
A nickjei úgy szaporodnak a hup.hu-n mint a Smith ügynökök. Ebben a szálban is találhatsz még párat belőle. Egy kis rejtvény, vajon melyik nick még? :-) Bár nem túl nehéz megfejteni. De itt nincs szükség még egy Neo-ra sem, hogy eltakarítsd őket. Elég használni az aláírásodban rejlő univerzális megoldást, amint azt már javasolták is neked.

-------

Developers! Developers!! Developers!!! Developers!!!!

Részben már te magad is felsoroltad. A többit egyedül is kitalálhatod.
Egy kis segítség:
Melyek azok a nickek, amelyek rendkívül gyors reakcióidővel reagálnak minden olyan commentre, ahol a Linuxot, Gnu-t, Fsf-t, Ubuntu-t, és általában azt a szabad-szoftver szemléletet tudják savazni, ócsárolni, amivel egyébként a hup.hu is foglalkozik ??
Melyek azok a nickek, amelyek egymással teljes egyetértésben kisebb tömeget próbálnak szimulálni?

Csak az a baj, hogy már láttam az Azonosság (Identity) című filmet, úgy még talán egyszer nézhető is volt. De ebben végtelen itteni szappanoperás feldolgozásban, már totál unalmas :-D

-------

Developers! Developers!! Developers!!! Developers!!!!

( muczy v | 2007. 06. 22., p – 11:04 )

Nemrég a beyond, most a ck...
Kár értük. :-(

Gentoo Karvaly

( Gabucino | 2007. 06. 22., p – 11:09 )

"forkolj, mert az jo"
"aki jo patchet kuld azt biztosan berakjak"
"EXPERIMENTAL, mond ez neked valamit?"
"bazar, mert kiraj."

Amugy fejlessze userlandben, ott konnyebb (c) turul16

"Another factor is ease of development. It is in general easier to write a user-level driver because (a) one wrong move does not result in a crashed machine, (b) you have access to user libraries (such as the C library), and (c) debugging is easier."

Nem magamtól találok ki ilyesmit :)

( bervi | 2007. 06. 22., p – 13:15 )

ez nem kell. grsec se. akkor még a végén használná pár ember, rendesen összecsiszolnák a többi fossal, és netalántán (!) korrektül használható valami lenne a kernelből

viszont kérünk soksok cfs-t meg ext4-et

nekem ne mondják azt, hogy technikai okai vannak. beteszik azt a rohadt opciót, default off, aztán használja aki kéri. működni működik látszólag, szóval itt csak bábszínház van. ennél sokkal használhatatlanabb szarok is kerültek már be a kernelbe

én nem használok ilyen patchset-eket, pont ezért nem. késnek a vanillához képest, és akkor is működnek, kivéve ha nem. nem lehet úgy valamit tesztelni ha nem használja senki. én meg nem tesztelni akarom a gépet hanem használni

Előbb-utóbb be fog kerülni szerintem grsec.

http://packages.gentoo.org/search/?sstring=hardened-sources
http://www.gentoo.org/proj/en/hardened/pax-quickstart.xml
http://www.gentoo.org/proj/en/hardened/grsecurity.xml

Gentoo -hoz vannak más patch válogatások is.

Nem kötelező Linus vanilliáját használni, erről szol a git egyetlet :)

ajánlom figyelmedbe ezt a mondatot:

"én meg nem tesztelni akarom a gépet hanem használni"

grsec-nél akkor dobtam a dolgot, amikor a paxot nem lehetett használni, mert depends on-nál KERN_GRSECURITY volt GRKERNSEC helyett, vagy ilyesmi, fejből nem tom.

írtam a csávónak levelet, nem válaszolt, de következő patchben már oké volt. aztán a következőben megint nem. nah, ha ilyen bénázások vannak, akkor inkább nem játszok vele.

arról nem is beszélve, hogy egy-két dolgot ha bekapcsolok/nék, akkor x lazán sz-rik a világra, és nem indul el. vagy pl. a networkmanager. vagy akármi. ezért kéne vanillában lennie, akkor a többi rühes program írója se sz-rhatná le, hanem normális programot kéne írnia

arra írnak nekem pl. új x-et? hogy jön ez egyáltalán ide? a hw támogatott, most nem erről van szó. inkább nézegesd a grsec option help-eket. 1-2nél: "ez nagyon jó blablablabla ja amúgy x-szel nem működik". meg a többi hülyeség, hol működik, hol nem, configure-re néha /bin/sh permission denied-ot dob, és egyéb nyalánkságok. ez csak pár példa. ja, és persze akadnak _ismert_ hibák is szép számmal, amit majd vagy javítanak, vagy nem, mert épp nincs kedve-ideje stb. a paxos csávó amúgy is nagyságrendekkel segítőkészebb, de egy fecske ugye nem csinál nyarat. szerintem jól jelzi a minőséget, hogy 5 hónapja nincs kiadás, csak test patch. akkor mit is várhatnánk? gentoosok meg ne jöjjenek nekem, hogy jaj az én szanaszéjjelszarrá patchelt kernelem pedig tök jól megy, mert nem hat meg. biztos neki kezdek 27 kernelt forgatni, hogy na, na, még egy picit... ezzazzzz most jó

mi lenne, ha nem az lenne a cél, hogy leugassuk a másikat, inkább olvasnád végig az első hozzászólásomat, hogy miről is ugatok. azóta már teljesen másról lett itt szó, egy darab érdemi hozzászólást nem kaptam, mert gentu über alles, meg meg vendor support, ésésés ie a portage-ben. de érdekes. kár, hogy ezek engem rohadtul nem érdekelnek.

> inkább nézegesd a grsec option help-eket.

a helpek altanos informaciok, semmit nem mondanak konkret disztrokrol, user kornyezetrol, stb. speciel az X mindig is mukodott PaX alatt, csak a megfelelo modul loadert kellett hasznalni (dlloader vs. elfloader) vagy statikusan kellett linkelni (mindezt megtalalhattad volna a forumon). az x.org vilag ota pedig a dlloader az alapertelmezett, tehat senkinek nem kene, hogy kulonosebb problemaja legyen (max nehany binaris GL implementacioban van textrel, azt lehet engedelyezni kulon).

ha megis, arra vannak bugtrackerek, forumok, listak, stb. gondolom csak az en figyelmemet kerulte el, szoval legyszi add meg a felvetett problemaidrol szolo riportok url-jeit, es utananezek.

> szerintem jól jelzi a minőséget, hogy 5 hónapja nincs kiadás, csak test patch.

miert, szerinted 2.6 vanillabol van mas is? mi csak a trendet kovetjuk ;-). amugy viccet felreteve megkerdeznem, hogy szerinted megis mibol lesz a kiadas?

?

ha jól megfigyeled, én nem paxról beszéltem, hanem grsecről

a grsec nem csak a paxból áll. fejből most nem tudom, hogy mely opciók voltak, amiket említettem, és most nem is áll módomban megnézni, de nem pax része volt. próbáltam minél szigorúbb lenni, amit lehet bekapcsolni. előtte persze elolvastam, mi mire jó, amit hülyeségnek-fölöslegesnek tartottam, azt nem kapcsoltam be. 1-2 opciónál volt ilyen, hogy "ez nem megy 1-2 dologgal, pl xfree". először forgattam egyet nélküle, OK. aztán vele, és láss csodát, x tényleg behal. ennyi.

ja, most jutott eszembe, hogy sok opciót pl. wine se szereti ("and several other programs" vagy mi), legalábbis azt írják a helpek, én meg hiszek neki, természetesen minden kombinációt nem játszottam végig

bugreport, jah, kár, hogy már párszor leírtam, hogy a gépemet nem testbednek szántam, de mindegy. valamiért inkább kidobom ezt az egész grsec dolgot, mint napokat kínlódok vele

jah, hát kiadásnak hívják hehe
hogy miből? hát, ha már az alkotó is úgy érzi, hogy elég jól használható valamit ütött össze. szerintem ilyen grsecnél nincs. pl írtad valamelyik témában (nem itt), hogy már fogalmam sincs melyik grsec részben valami bitfield-ek el vannak cseszve, "hát az most nem megy, majd egyszer jó lesz". és ez megint _nem_ pax rész volt, mielőtt ezt is magadra veszed. na, szóval szerintem az ilyen azért gáz.

ezek a példák úgy jutnak eszembe, hogy 1) nem használtam sokáig a grsec-et 2) nem végeztem módszeres kutatást a grsec lejáratására

( Replaced | 2007. 06. 22., p – 14:55 )

azert nincs szukseg mar erre az agra, mert a mainstream linuxkernel mar technologically superior

--
Those who do not understand Unix are condemned to reinvent it, poorly

( joco01 v | 2007. 06. 22., p – 14:56 )

nem értem, minek a vita, miért nem lehet beletenni mindkét ütemezőt, aztán konfignál lenne választási lehetőség, hm?

--
joco voltam szevasz

( bra | 2007. 06. 22., p – 23:54 )

Hát ha valóban tud valamit a faszi, akkor felkészültség és mentalitás függvényében lehet tanulgatni valamelyik más nyílt forrású stuffot és javítani inkább azon.
Van rengeteg, nehéz lesz választani.

( bastya_elvtars | 2007. 06. 25., h – 00:31 )

BTW ki is ugatta a másik threadben, hogy akinek nem tetszik a fejlesztési modell, keressen másik projektet?
Elkésett.
It doesn't matter if you like my song as long as you can hear me sing

Vicces, hogy ezt is a fejlesztési modell nyakába varrod. Emlékszem még az MPlayer-re, amikor jött az orosz csóka, hogy ő majd többszálúsítja az MPlayer-t. Aztán amikor beintettek neki, akkor elballagott. Vagy emlékszem, amikor Dillon és a FreeBSD fejlesztők állandóan szanaszéjjel flame-lték a freebsd-* listákat, mert Dillon-nak olyan ötletei voltak, amik nem illettek a képbe. Mit csinált Dillon? Elment. Természetesen a Linux fejlesztési modell miatt. :))

Millió olyan eset van millió más projektnál, ahol ha valakinek a javításai, ötletei nem kerülnek be, akkor az megsértődik, vagy nem tetszik neki. Mi ebben a nagy csoda?

--
trey @ gépház

Nem tudom, hogy jön ide a Linux fejlesztési modellje... Dillon-t kiqrták, mert faszkodott a többei fejlesztővel (vagy legalábbis megvolt a maga véleménye, amit kevés helyen díjaznak *khm*). De kiqrták Theót is a NetBSD-ből, modjuk őt azért, mert már égett a pofájuk a baromságai miatt. Ezek nem a legjobb példák.
Amúgy el kell olvasni a wikit, ez kicsit más téma. Itt tulajdonképpen valaki jót akart, csak a redhates "mutyigépezet" nem hagyta érvényesülni.
It doesn't matter if you like my song as long as you can hear me sing

"Nem tudom, hogy jön ide a Linux fejlesztési modellje.."

Talán olvasd el a kettővel feljebb levő hozzászólásod.

"Amúgy el kell olvasni a wikit, ez kicsit más téma. "

Elolvastam. Az egy szemszög. A fejlesztőjé. Talán érdemes lenne meghallgatni a másik oldalt is.

--
trey @ gépház

A fejlesztési modell sehogy. Te hoztad itt szóba, te próbálod a fejlesztési modell nyakába varrni azt, hogy Kolivas rendkívül innovatív motyója nem került be a mainline kernelbe. Én meg azt mondtam, hogy nincs ebben semmi csoda, szerintem semmi köze a fejlesztési modellhez, egyszerűen csak nem illett a jelenlegi tervekbe. Mint például az MPlayer fejlesztési tervébe a threaded megvalósítás annak idején, vagy éppen a FreeBSD terveibe a Dillon féle más elképzelés. Kolivas ha meg ezen besértődött, akkor legfeljebb visszamegy altatóorvosnak. Vagy mi a szakmája.

--
trey @ gépház

( muczy v | 2008. 01. 17., cs – 14:11 )

Bár elég régi a topik, és elég sok az offtopic hozzászólás, de a levelezőlista szerint itt folytatódik az unofficial ck patch fejlesztés:
http://waninkoko.info/ckpatches/
Én most kipróbáltam egy 2.6.23.14-es vanilla kernelen, és eltekintve két hunk üzenettől simán felment, lefordult, és megy is már egy ideje.