Linus véleménye a CFS vs. SD témában

Kernel

"Az emberek, akik azt hiszik, hogy az SD "tökéletes" volt, nem vesznek tudomást a tényekről," jelentette ki Linus Torvalds egyik levelében, amelyben megindokolta, hogy miért a Molnár Ingo-féle Completely Fair Scheduler-t (CFS) választotta Con Kolivas Staircase Deadline (SD) ütemezőjének ellenében. Részletek a KernelTrap cikkében.

( bastya_elvtars | 2007. 07. 29., v – 20:57 )

Így 2 hét után hirtelen beugrott neki két kódsor között, hogy miért is fosott Kolivas fejére.
Szerfölött hihető.
It doesn't matter if you like my song as long as you can hear me sing

Ja, és idáig hagyta (pont ő), hogy az emberek azt higyjék, hogy Ingóval egy tálból cseresznyézik -- ami természetesen egy rosszindulatú, aljas rágalom --, csak most már elege lett a flame-ből az LKML-en.
It doesn't matter if you like my song as long as you can hear me sing

Nem értem mit kellene helyére tenni. Két munka közt kellett dönteni. Az egyik mögött egy lelkes hobbista ausztrál altatóorvos, a másik mögött meg egy hosszú ideje ütemezőkkel foglalkozó profi kernelfejlesztő és egy cég áll. Az egyiknél van garancia a kód hosszútávú karbantartására, a másik esetben semmi. Egyrészt Kolivas bármikor besértődhetett volna és leléphetett volna (mint ahogy meg is tette), de kaphatott volna kinevezést is mint orvos és szögre akaszthatta volna a kernelcsákányt. Ez egyetlen szempont. Többről volt szó. Linus jól döntött.

--
trey @ gépház

Mindezektől függetlenül kicsit furcsa a stílusa Linusnak, mintha személyeskedés is állna döntése mögött. Bár lehet csak képzelgek, nem kellett volna megnéznem "A 23-as szám"-ot :D

Azonkívül nem titkoltan tesz arra, hogy 3D-s alkalmazások igényeit is figyelembevegyék, holott pont ő magyarázta azt, hogy az arany középutat kell "járni" egy mindenkinek megfelelő ütemező használatával.

Azonkívül a végén megjegyzi, hogy nem első alkalommal lett lecserélve az ütemező, és a jövőben is lesz még csere, mivel az igények változnak. Szóval jöhet még akármi, meglátjuk, ha kijön a 2.6.23 mi lesz.

az is lehet, hogy a 24-esbe már sd lesz, de ennek a valószibűsége 0.

tudom, tudom 5 00 000 000x lett már mondva de a 2.7-es tree-t el kellene indítani és azt alapjaiban megváltoztatni, pl.: utemezők, uj fs-ek, egyszóval minden ami uj ... és abba lehetne kisérletezgetni.

Nekem mindig igazam van, ha nem, akkor nincs igazam, szoval megint igazam van hogy nincs igazam.

debian 4.0 - linux-2.6.22-pancs1-wifi0 - 2.6.22 kernel madwifivel itt

A multkori cikket elolvasva, Kolivas csinalt (vagy akart?) cserelheto utemezot is. Tehat nem kellett volna *csak* az ingo felenel leragadni. (azt, hogy runtime lehetett volna cserelni azt nem tudom)

Es azert Kolivas mar egy ideje karbantartotta (2002?).

Ja, es (meg szinten a multkori cikk), Kolivas a Desktop felhasznalokkal foglalkozott, mig szinte
az osszes kernelfejleszto valamilyen nagy cegben dolgozik, es a vallalati szempontokat vesz figyelembe. Nem is meglepo, hogy a Ingo utemezojenel rogton egy quake-es kezdett sirni, hogy Kolivas-e gyorsabb ...

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

akkor ezt nézzétek meg!

idézet: 


         2.6.22-ck1                         2.6.22-cfs-v19
   ------------------------            ------------------------
   quake + 0 loops | 41 fps            quake + 0 loops | 41 fps
   quake + 1 loop  |  3 fps            quake + 1 loop  | 41 fps
   quake + 2 loops |  2 fps            quake + 2 loops | 32 fps
   quake + 3 loops |  1 fps            quake + 3 loops | 24 fps
   quake + 4 loops |  0 fps            quake + 4 loops | 20 fps
   quake + 5 loops |  0 fps            quake + 5 loops | 16 fps

Nekem mindig igazam van, ha nem, akkor nincs igazam, szoval megint igazam van hogy nincs igazam.

debian 4.0 - linux-2.6.22-pancs1-wifi0 - 2.6.22 kernel madwifivel itt

Ha esszeru keretek kozott meg tudnam csinalni (hint: pl. elerheto lenne a pontos reprodukciohoz szukseges lepesek leirasa) akkor talan. De egyebkent meg annyira nem foglalkozom 3D desktoppal a linuxon, hogy napokig szenvedhetnek vele.
Nekem pedig ennyit nem er.

--
Gabriel Akos

amugy meg Kolivas két célpatchet készített mindig
egy -ck és -cks patchsetet, a ck az átlag desktop a cks pedig a server patchset volt.

Nekem mindig igazam van, ha nem, akkor nincs igazam, szoval megint igazam van hogy nincs igazam.

debian 4.0 - linux-2.6.22-pancs1-wifi0 - 2.6.22 kernel madwifivel itt

egyáltalán nem, mivel a linux NEM DESKTOP OS!!! aki meg annak haszálja az meg tudja mire képes alapból és mit tud belöle kihozni "saját két kezü munkával". SZVSZ

Nekem mindig igazam van, ha nem, akkor nincs igazam, szoval megint igazam van hogy nincs igazam.

debian 4.0 - linux-2.6.22-pancs1-wifi0 - 2.6.22 kernel madwifivel itt

Miért ne lehetne desktop os? Én is arra használom már lassan 3 éve.
Ha nem lenne érdekelt desktop téren akkor hol lenne ma az ubuntu, suse, stb? Meg akkor minek egyátalán X bele?
Nagyon is valós igény a desktop használat. Az más, hogy én is kitartok azon véleményem mellett, hogy amennyiben lehetséges, úgy "rakjanak bele" választási lehetőséget, mert ugye a két kernel ág teljesen nonszensz lenne, ahogy Linus is fogalmazta.

amugy én is annak haszálom és tudom mit tudok belüle kihozni és nem sírok, ha valami nem működik, hanem próbálom megoldani (vagy scriptelek vagy programozok vagy google ...), de mondjuk Bözsinéni Pistikéje aki előszr lát linuxot és azzal kezdi: anyu nem mennek a játékok az inkább maradjon a windowsnál ... (de nem kívánom folytatni, mert csak magamat húzom fel)

Nekem mindig igazam van, ha nem, akkor nincs igazam, szoval megint igazam van hogy nincs igazam.

debian 4.0 - linux-2.6.22-pancs1-wifi0 - 2.6.22 kernel madwifivel itt

"Én is arra használom már lassan 3 éve."

Attól még nem az.

"mert ugye a két kernel ág teljesen nonszensz lenne"

Márpedig máshogy kell egy desktop OS-t konfolni és máshogy egy szerver OS-t. Szerver OS-nél nem gond, ha a nem éppen a leg reszponzívebb a rendszer GUI/CLI része, viszon k.va gyorsan végzi a dolgát. Desktopon viszont kifejezetten igény a gyors válasz.

Ehhez nem kell két kernel ág, csupán megfelelő tervezés és modularitás.

_____
Legyél egyéniség! Ne köve$d a divatot! Használj te is Ubuntut! -- Nem vagyok egyéniség. :)

Pinyó, nem értek egyet veled. Valóban, a múltban nem volt Desktop OS. De muszály valami ingyenes alternatíva, mert A Microsoft szép lassan egyeduralkodó lenne a piacon.

Ha azt mondod, hogy a *BSD nem desktopra való, azt még meg is tudom érteni. De hogy a linux nem Desktop OS... hát nem tudom... Biztos a Canonical és a Novell döntéshozói a hülyék...

Tényleg nem értelek. Miért ne mehetne el a Linux a desktopra való optimalizálás felé is egy picit? Azért mert jelenleg a linux 80%-ban serverre van használva, még nem jelenti azt, hogy nem kellene ezen változtatni.

amit itthon haszálok debian alatta "saját" kernel van és azt is ugy optimalizálom, mintha server lenne, mert NEKEM igy gyorsabb, pl a PREEMTING-et bekapcsolom akkor a GUI-s prg sebessége novekszok, de minden más lassul (file és i/o műveletek). a másik meg hogy a linuxot nem kellene click & run-osítani mert ugyancsak SZVSZ undorító égy apt vagy rpm parancssorból sokkal hatékonyabb, de ezt sok desktop user nem képes felfogni és nyavajog, hogy milyen szar, pedig csak ö nem tudja használni és NEM IS AKARJA MEGTANULNI, de ilyen hozzáállással senki ne akarjon linuxozni vagy *bsd-zni mert csak csalódik benne.

szerk:

tudom ez most hülyén fog hangzani akkor c&r-es telpítést akar az haszáljon w32/w64-et vagy desktopbsd-t (ha jól tudom az is c&r-es technológiát haszál FIXME )

szerk2:

FIXME: pc-bsd és nem desktop-bsd

Nekem mindig igazam van, ha nem, akkor nincs igazam, szoval megint igazam van hogy nincs igazam.

debian 4.0 - linux-2.6.22-pancs1-wifi0 - 2.6.22 kernel madwifivel itt

tudom, de a legtöbb user ezt szajkózza és ezt nem személyes támadásnak szántam. de akkor hozzanak létre egy olyan desktop distribet vagy javítsák ki az ubuntut, hogy ne legyen tele ennyi buggal és szerintem a desktop user aki először lát linux az leszarja, hogy 2.6.22 vagy 2.6.16-os kernel van alatt, csak legyen stabil.

Nekem mindig igazam van, ha nem, akkor nincs igazam, szoval megint igazam van hogy nincs igazam.

debian 4.0 - linux-2.6.22-pancs1-wifi0 - 2.6.22 kernel madwifivel itt

Én most is leszarom, pedig több éve használgatok linux-ot. A másik amit kihagytál, az pedig az, hogy ne kelljen már nekem fél napot google-öznöm ahhoz, hogy a retek wifi hajlandó legyen működni pl. Ubuntu alatt. Ha viszont nem cél a Desktop orientation akkor a Beryl-re minek pocsékolnak annyi munkaórát? Mindet átzavarni kernelt forrasztani!^^

Ezért a mondatodért holnap már Guantanamóról fórumozol. :)))

a beryl-t nem a kernelfejlesztök csinálják, hanem a VPS buzik akik azt akarják, hogy a linux desktopon hóditson, de ezt hülyeségnek tartom. Amugy a wifi-t a gépemen én magam raktam össze (szeretem a kihívásokat) és ez a különbség a desktop user akkor azt akarja, hogy minden mindjárt működjön és az között, aki szeret "hegeszteni" és nem adja fel az első negatív élmény után.

Nekem mindig igazam van, ha nem, akkor nincs igazam, szoval megint igazam van hogy nincs igazam.

debian 4.0 - linux-2.6.22-pancs1-wifi0 - 2.6.22 kernel madwifivel itt

Ugyan miért lenne hülyeség a Linux desktopra. Elvégre több asztali gép van mint szerver... A te szempontjaidat szerintem nem kellene általánosítani...

"a wifi-t a gépemen én magam raktam össze" meg elég tág fogalom, saját chiped, firmawared van, vagy belőtted hogy működjön a nem desktop gépeden?

Amúgy meg nincs mindig idő hegeszteni. A legjobb ha megy elsőre... Kevés olyan embert ismerek aki szeret hegeszteni - én ráveszem magam, de közvetlen ismeretségemben max 10 ember van ilyen és mind informatikus. Ez olyan mintha mindenkitől azt várnánk el hogy egy kisebb műtétet el tudjon végezni - annak ellenére, hogy maximum elsősegély nyújtására elegendő tudása van...

Az emberek egy szolgáltatást vesznek igénybe a számítógéppel. Nézd meg hogy áll most az autóipar. Régen ott is lehetett "hegeszteni" Trabantot, Skodát, Ladát... Ma az is inkább egy szolgáltatás ami elvisz A-ból B-be és a szervizben javítják, állítják be az autót. Persze neki lehet most is esni, de több egyedi eszközre is szükség lehet. Egyszerű eszközökkel azt sem tudod elérni, hogy a szerviz szükségességét jelző "flag"-et kikapcsold...

KAMI
--
OxygenOffice | OpenOffice.org | A Böngésző - magyarul | Kiterjesztések - magyarul

A vegfelhasznalo szempontjabol az esetek nagy reszeben abszolut nem erdekes, hogy azt valaki osszehegesztette vagy pedig ket klikkelessel megoldotta, a vegfelhasznalot egy dolog erdekli: mukodjon. Minnel gyorsabban es minnel egyszerubben.

Hat ezert az Ubuntu a legnepszerubb distro most. Lehet hogy x distro alatt nehany parancssoros apt-get hivassal meg konfig fajl editalassal osszehegesztesz egy Samba-t, viszont Ubuntuban jobbklikkelsz egy folderen, nyomod, hogy "Share", erre o felteszi a Samba-t es kirakja mint share-t. Biztos bennem van a hiba, de nekem nem kihivas Samba-t hegeszteni, mert nem vagyok foallasu Samba admin, a munkamat kell elvegezzem, ahol egy konyvtar megosztasa a munka 0.01%-a.

csak szimplán azért "fájna", mert utána az lenne a tendencia és a distrok 99%-a átállna a seggkinyalós módba, amit én rühellek és jobban szeretem, ha ez os azt csinál amit és akaork és nem azt amit gondol.

Nekem mindig igazam van, ha nem, akkor nincs igazam, szoval megint igazam van hogy nincs igazam.

debian 4.0 - linux-2.6.22-pancs1-wifi0 - 2.6.22 kernel madwifivel itt

Az egész a választás lehetőségéről szól. Ha az lesz amitől a legjobban tartasz (99% nedvesített hátsófeltáj kényeztetés), még akkor is választhatod azt, hogy pl. használsz egy woody-t, nem muszály neked is a tömeggel egy irányba haladni. :)

[FUN]
Erről eszembe jut az a vicc, amikor valaki az autójával az autópályán hajt, veszettül kerülgeti az autókat miközben a rádióban bemondják.. Vigyázat egy őrült autós a forgalommal szemben hajt! - mire emberünk felcsattan.. Mi az hogy egy? Mind!
[/FUN]

ui.: nem kell annyira félni, a 2.4-es kernelfát is karbantartják még :P Vagy választhatod amit Linus választott anno 90-91-ben. Nem tetszett neki a Minix, csinált inkább egy sajátot :)

ebben is van valami, de a kernellel (2.6) eddig sok bajom nem volt, ami meg nem kell azt eddig is kiszedtem és ki is fogom szedni (pl modulok támogatása ...). Az Etch felrakésa után az volt az első, hogy "visszahülyitettem Sarge és Woody közé", mert rühellem ez "önkényes" rendszereket. Amugy a Sarge az egyik kedvenc debian-om, (és szerintem észre lehetett venni a többi hozzászólásomból is, nem csak ebben a topicban, bármelyikben, a valamihez ragazkodom a saját nézeteimhez [XFS, debian, sorolhatnám még ...] .)

Nekem mindig igazam van, ha nem, akkor nincs igazam, szoval megint igazam van hogy nincs igazam.

debian 4.0 - linux-2.6.22-pancs1-wifi0 - 2.6.22 kernel madwifivel itt

"pedig csak ö nem tudja használni és NEM IS AKARJA MEGTANULNI"

Sajnos ki kell ábrándítsalak: az egyszerű mezei desktop user NEM akarja megtanulni. Csak használni. Azt meg legegyszerűbben (jelenleg) c&r formában lehet. *

De egyébként nem az örökös konzol vs clickclick -ről van most szó, hanem arról, hogy sebességben mire optimalizálnak.

Szerk.: *(<halkan jegyzem meg>És most jön az, hogy el lehetne már végre dönteni, hogy kellenek azok a hülye desktop userek és akkor a Linux is alkalmazkodik a desktop igényeknek vagy nem, de akkor senki se sírjon azért, hogy miért nem Linuxot használ a fél világ.</halkan jegyzem meg>)

_____
Legyél egyéniség! Ne köve$d a divatot! Használj te is Ubuntut! -- Nem vagyok egyéniség. :)

sebességben a desktopra optimlizált az arra megy hogy minden csili-vili kattintásra ugorjan, a serverre meg inkább az io és fs műveletekre, spec én a másodikat jobban találom.

Nekem mindig igazam van, ha nem, akkor nincs igazam, szoval megint igazam van hogy nincs igazam.

debian 4.0 - linux-2.6.22-pancs1-wifi0 - 2.6.22 kernel madwifivel itt

CONFIG_HZ_1000=y
CONFIG_PREEMPT=y

ez a két opció nagyot dobhat a gui-s programok haszálatában, ugyanakkor a lemezműveleteket visszafogja.
(PREEMTing nélkül másolás 2hdd között 40-45MB/s, PREEMPT=y 32-35MB/s)

Nekem mindig igazam van, ha nem, akkor nincs igazam, szoval megint igazam van hogy nincs igazam.

debian 4.0 - linux-2.6.22-pancs1-wifi0 - 2.6.22 kernel madwifivel itt

Nem lehet, hogy arról van szó, hogy a "desktop user" egyszerűen nem az OS telepítsével szeretne szívni, hanem az érdemi munkájára koncentrálni? Egy OS nem l'art pour l'art, önmagáért való, hanem hogy használni tudd a dobozt. Emiatt alap, hogy ne azt kelljen tuningolgatni, minden más ezután következik.

---
"Neszójábee! Linugz!" - ng

Nem arról van szó, hogy a buherálni vágyók fognak kiveszni, hanem arról van szó, hogy akik nem akarnak buherálni, csak használni, annak ne kelljen már buherálni. Nem ugyanaz.

_____
Legyél egyéniség! Ne köve$d a divatot! Használj te is Ubuntut! -- Nem vagyok egyéniség. :)

Quake Pistike problemai desktop OS eseten sem mervadoak. Quake Pistike vegyen konzolt jaccani, ott gyakorlatilag nincs OS, egy processnek kell full gazzal futnia. Desktop OS alatt fusson jol es gyorsan az OOO, az Eclipse es egyeb IDE-k meg engineering toolok, CAD, Design cuccok (pixel, vektor, html), de hogy Pistike Kvekje szaggat, oszinten megmodon, leszarom. Pistike vesz PS3-at ha jaccani akar. Ha meg apuci PC-jen akar jatszani akkor meg igy jart.
Valahogy sokkal jobban izgat amikor "A" desktop OS egy ujrainditas utan fel oran at "applying your settings" a melohelyen es emiatt elcsuszok a melommal. Viszont a Kvek nem szaggat. Az en kriteriumaim szerint ezek utan az ablax nem desktop OS, mert mindig a legkritikusabb pillanatban fossa ossze magat.

Az viszont biztos, hogy különböző igényeg márpedig vannak. Egyértelmű, hogy nem lehet egyszerre mindenki kedvére tenni.
Különben is a Linux és a köré épített rengeteg minden filozófiája az, hogy TE dönthetsz, mit akarsz használni. Legalábbis én így gondolom :)
Miért nem lehetett volna úgy beolvasztani a kettő kódot mint nemrég a SLUB allocator-t -> hogy a felhasználó dönt melyiket (forgatja) használja? Kecske vs. káposzta!

igen ez a választás a 23-ban még benne van, de a 24-ben már nem lesz, mivel ki akarják szedni a slabot, de ez még több akadályba ütközik (felhaszálók). most nem keresem meg az email-t de lkml-en fenn van egy egész hosszú thread

Nekem mindig igazam van, ha nem, akkor nincs igazam, szoval megint igazam van hogy nincs igazam.

debian 4.0 - linux-2.6.22-pancs1-wifi0 - 2.6.22 kernel madwifivel itt

Aha, és Ingónak meg derogált volna Con cuccát továbbfejleszteni, ezért nem is tárgyalt vele, hanem írt egy másikat (a Con-féle alapján), ami hipp-hopp bekerült. Most akkor nem értem, hogy Con személye nem volt garancia, vagy fos volt az ütemező, vagy lesz még valami verzió? Egyébként meg az, hogy hobbista aneszteziológus, meg ilyen indokok, ezek hámozott léggömbök, mert múltkor arra ment a circlejerking, hogy valami háziorvos az összes webcamdrivert maintaineli, és hogy az milyen zsír.
Szerintem nem lenne ekkora hírverés, ha egyértelmű lenne az ügy.
It doesn't matter if you like my song as long as you can hear me sing

Nincs ellentmondás, mivel Ingo is inkább Con ütemezője alapján írt egy másikat, nem a sajátját fejlesztette tovább, de kötözködj csak, úgyis hiányzott mára egy jó kis röhögés.
It doesn't matter if you like my song as long as you can hear me sing

Átírtam, hogy legyen benne nick, ahogy kérted:

"bastya_elvtars, te félreértetted a linket.

Te, bastya_elvtars, ugyebár tisztában vagy a tényekkel, ezért neked, bastya_elvtars, elég csak újraolvasnod a hozzászólásokat ahhoz, hogy magadtól is felismerd, ki is az, aki elferdíti a tényeket."

mivel Ingo is inkább Con ütemezője alapján írt egy másikat, nem a sajátját fejlesztette tovább, de kötözködj csak, úgyis hiányzott mára egy jó kis röhögés.

Hozod a formad. A fenti allitasodat ala is tudod valamivel tamasztani vagy szokasod szerint megint a levegobe beszelsz? A CFS es az SD-ben egyetlen kozos dolog van: ugyan azt a kovetelmenyrendszert valositjak meg, mas-mas modon. Nem tudom mennyire vagy otthon a szotveriparban, de ha ket teamnek ugyan azt a kovetelmenyspacifikaciot adod, es mindketto megoldja onalloan a feladatot, egyik teamre se foghatod ra hogy a masik munkajat fejlesztette tovabb. A kovetelmenyeket CK dolgozta ki ez teny, de mind o, mind ingo sajat designnal es implementacioval valositotta meg a szoftvert ami teljesiti akovetelmenyeket. A "gepsoron" jo esetben a szoftvermernok munkaja kovetelmenyek kezhezvetelevel kezdodik, azok megalkotasa normalis esetben a product/project manager role feladata.
Mindettol eltekintve, valahogy nugodtabb vagyok ha egy redhat altal foglalkoztatott szoftvermernok utemezoje fut a gepemen mint ha egy bizonyitottan hisztis ausztral orvose futna.

amugy ti ossze vagytok nove? Most Bastya elvtars batyja vagy esetleg egy testen osztoztok? Vagy hozzad szalad sirni hogy Apuuuuuu baaaantanaaaaaaak!

BTW egy k.va munkahelyen szoftvermernok nem szarakodik a windozaval. Ahoz tul draga mulatsag. Arra vannak az IT-sek, akik ha tekernek egyet-egyet valami domain policyn, bizony-bizony elofordul hogy a fenti jelenseg lesz a vege. Sot adott esetben az IT valasza a problemara "igyal meg egy kavet, mire vegzel valoszinu beenged" volt.

Majd ha egyszer dolgozol ilyen kornyezetben, megtudod. Addig meg talan hatrebb az agarakkal. Mellesleg innetol betartom a jotanacsot hogy ne vitatkozz olyannal akivel nem szeretned ha osszekevernenek.

Nézd, nem azt mondom, hogy a kódot felhasználta (tegyük fel, hogy nem), de ugye Con bizonyítottta, hogy az adott scenario lehetséges (ezt Ingo mondta), tehát neki ez eszébe sem jutott.

nugodtabb vagyok ha egy redhat altal foglalkoztatott szoftvermernok utemezoje fut a gepemen mint ha egy bizonyitottan hisztis

Ezen visítva röhögtem, mert hirtelen beugrott az OpenSSH meg az Emacs.
It doesn't matter if you like my song as long as you can hear me sing

Es RMS eddig hanyszor jelentette mar be hogy csesszuk meg az emacsot meg a GCC-t, o kiszall a GNU-bol ha ez meg ez meg ez nem tortenik meg? Mert CK ezt tette. Es valoban kiszallt. Remelem tenyleg valoban, mert ugyan senki nem potolhatatlan, de mondjuk ha a linux utemezo hirtelen karbantarto nelkul maradna, az okozna kellemetlensegeket.
Mondjuk Linux se mai csirke mar, szerintem meg tudja nagyjabol itelni letfontossagu kodokat kitol fogad el, es ebben nem csak a fejlesztoi kvalitasok jatszanak nala.

"Aha, és Ingónak meg derogált volna Con cuccát továbbfejleszteni, ezért nem is tárgyalt vele, hanem írt egy másikat (a Con-féle alapján), ami hipp-hopp bekerült. Most akkor nem értem, hogy Con személye nem volt garancia, vagy fos volt az ütemező, vagy lesz még valami verzió?"

Mondd, te elolvastad, amit linkeltem?

"Egyébként meg az, hogy hobbista aneszteziológus, meg ilyen indokok, ezek hámozott léggömbök, mert múltkor arra ment a circlejerking, hogy valami háziorvos az összes webcamdrivert maintaineli, és hogy az milyen zsír."

Zsír. Megcsinál valamit, amit más nem. Itt másról van szó. Itt megcsinál Kolivas valamit, amit más már évek óta csinál. Linus meg dönt ezer szempont szerint, hogy a Linux-nak, neki melyik a legjobb. Megteheti.

"Szerintem nem lenne ekkora hírverés, ha egyértelmű lenne az ügy."

Egy CPU ütemező csere általában nagy visszhangot vált ki. Akkor pláne, ha egy prímabalerina össze is sírja magát miatta és fut fűhöz fához panaszkodni.

--
trey @ gépház

"Zsír. Megcsinál valamit, amit más nem. Itt másról van szó. Itt megcsinál Kolivas valamit, amit más már évek óta csinál. Linus meg dönt ezer szempont szerint, hogy a Linux-nak, neki melyik a legjobb. Megteheti."

Ingo CFS-e 62 óra alatt készült el, és kb 3 hónap után olvasztották a kernelben, tehát effektíve Kolivas volt az aki éveken át csinált valamitn nem Ingo.

(Bár lehet félreértettem amit írtál)

mintha pejorativ modon emlitened a lelkes hobbista jelzoket, pedig ez imho nem tul szerencses. szazszamra lehetne sorolni azokat a fud szagu cikkeket altudomanyos elemzeseket, amelyek a lelkes hobbista fejlesztoket a gnu/ linux rendszerek fo hatranyakent emlitik az osszehasonlitott profi rendszerrel szemben. ez ugyan ma mar nem tekintheto igaznak, am korabban valoban igaz volt, kulonosen a gnu/linux linux reszere. Ingo is hobbistakent kezdett kernelt fejleszteni, majd az Fsf ugy talalta erdemes a tevekenyseget havi 1000usd tamogatassal osztonozni, ami akkoriban eleg nagy penz volt magyarorszagon. a kereskedelmi unixok, vms, windows, vagy eppen a bsdk profi cegek vagy neves egyetemeken szulettek. a linux pedig csak egy egyetemista hazi hobbiprojectjekent indult. mostanra megis szep eredmenyeket ert el. es nemcsak a mai napokra valt hasznalhatova, szinte a kezetektol az volt, csak a potencialis felhasznaloi kor bovult idorol idore.egy korabbi cikk kapcsan, felhivtad a figyelmem a szohasznalat fontossagara, helyesen. itt szinten errol van szo imho.
egyebkent kolivas utemezojenek valoban vannak problemai. probalgattam eleget. egy erosen szamitasigenyes, kulonosen multimedias alkalmasasok mellett a tobbi process szinte elveszit minden gepidot. egy ilyen gepre kotott x terminalok szinte hasznalhatatlanok ilyenkor, meg egy karakteres soros konzol is borzalmasan lassu. Ingo kodja ezert valoszinuleg alkalmasabb lesz, szelesebb koru hasznalatra. midenesetre szerencsesebb lett volna, ha Ingo patcheli Kolivas kodjat, vagy beteszi Linus mindket kodot a vanilla kernelbe. a szabadszoftverekkel kapcsolatos szabadalmi anomaliara igy sajnos pont Linus hivta fel a figyelmet. erre pedig nincs megoldasa sem a gplv2 sem a v3 valtozatanak.

pont az a nyílt forráskód legfőbb előnye, hogy nem kötődik ezer szállal a fejlesztő céghez ill coderhez. ha az aktuális fejlesztő befejezné a munkát, a forráskód elérhetősége miatt azonnal átveheti egy másik programozó a helyét. Kolivas kódja még normálisan kommentezett és áttekinthető is. de még az olyan összehányt spagettikód is mint az egykori netscapeé is elegendő kiindulási alap volt ahhoz, hogy ma firefox legyen belőle. a kezdeti komoly problémákat ott elsősorban a motif függőség okozta, és nem is a kiindulási kód minősége.
Ingo ütemezője egyébként sem az ultimate ütemező, még számtalanszor megváltozhat az egész kód. és Ingot is leütheti a villamos, szívrohamot is kaphat, ugyanúgy ahogy Kolivas is valóban megunhatja a fejlesztést. mindkét esetben a nyílt forrás miatt viszonylag könnyen átvehető a kód más fejlesztők által, ahogy egyébként Ingo is megírta az új ütemezőjét, CK kódja alapján.

( zilahu v | 2007. 07. 30., h – 12:05 )

Elolvastam a cikket, és elolvastam a hozzászólásokat. Nem értem mire ez a nagy vita? Kolivas nagyjából leszarta a hibajelzéseket és azok kijavítása helyett osztotta az eszet az embereknek. Ingo pedig fogta magát és kijavította a jelentett hibákat. A két ütemező teljesítménye között nincs különbség (ugye, független, double-blind teszteket végeztek velük), mindkettő jobb mint a mostani. Ezek után teljesen érthető hogy Linus a CFS-t választotta. Ráadásul Kolivas besértődött és bejelentette, hogy felhagy a kernel fejlesztéssel. Szóval miről is beszélünk egyáltalán?

én azt nem értem az egész ugató bagázsban hogy ha éppen a hobbisták foltoznak valamit akkor az a baj, hogy "mekkora bazár és kupleráj az egész", ha meg egy több éve az adott területen nagy szoftvercégnél dolgozó profi végez el egy szükséges módosítást, akkor meg mindjárt jön a "nagycég biztos lenyúlta mások munkáját és különben is fakk"

most erre mit mondjak? úgyis szétflémeltétek a topicot, ahelyett hogy bárki akinek fájt a váltás végzett volna valami mérést...

( bra | 2007. 07. 30., h – 12:38 )

VNLB fejlesztő véleménye a stabil API-ról:
#if (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,22))
#error 2.6.22+ kernels are not supported yet, because some oversmart nerd \
has deleted support for destructors from SLABs in those kernels and was \
unresponsible enough to made that without even set it in the deprecated \
status for some time to allow depending on it projects fix it without \
disturbing their users. Blame him for that! So, now to be usable on \
2.6.22+ kernels SCST requires a complete rewrite of one of its major low \
level parts: all kmem_cache_*() functions in this file should be replaced \
with new ones with similar functionality. I'm not sure I will have time for \
that in the near future, therefore you are welcome to implement that. \
Don't hesitate to ask me how to do it most effectively. VLNB.
#endif

:)