Mi várható a Linux 2.6.15-be?

Tokom eldurran ettol a kerneltol. Meg a 2.6.14 is ingatag a masodik patch utan is, de mar a kovetkezo releasere keszulunk. Az mar tuti, hogy nalam marad a 13-as egy darabig aztan patchelgetek hozza inkabb kezzel.

Muszaly ezt ilyen eszeveszett tempoba nyomni? Uldoznek gyerkek?

Hajajajj... :(

Az udev vs devfs "csataban" en nem alltam senki oldalara nem azert mert nem erdekelt, csak mert nalam a temahoz jobban ertokre biztam a dontest, es a valamennyire a velemenyem alakitasat (olvasgattam erveket/ellenerveket), viszont itt most latok egy kis bibit az udev-vel szemben, amit leirok es valaki okosabb, majd utbaigazit jol.

Nem foghato fel az udev hatranyanak, hogy a userpace-kernelspace komponensek miatt a userspace toolnak frissulnie kell, kulonben nem hasznalhato az uj kernel dinamikus /dev konyvtar tamogatassal? Devfs eseten az egyutt fejlodott a kernellel, nem volt userpace fuggoseg, igy akarmilyen oreg disztrot is futtatott az ember, akkor is tudott uj kernel hasznalni. (Jo tudom, hogy module-init-tools meg ilyenek akkor is kellettek a 2.6 tamogatasahoz, de nem a 2.6 fan beluli valtozasokat kovetesehez)

Ellenben az udev olyan szintu szetturasa, hogy userspace "inkompatibilitast" okozzon, az opcio volt es nem szukseges lepes :)

Ez az egesz szerintem nem udev/devfs kerdese, a scsi ioctl-ekkel is ugyanezt csinaltak. Ja meg persze a netfilterrel is.

A devfs-hez is volt egy devfsd vagy hasonlo daemon ami futott userspace-ben. Azt nemtom, hogy mit csinalt, de volt.

es feltetlenul muszaj ezt az ugynevezett __stabil__ agban megcsinalni? mindennek van ara, csak nem mindegy, hogy adott nyeresegert mit aldozol fel. a linux nem attol lesz enterprise szintu OS (pontosabban ettol nagyon nem lesz az), mert kernel alverzionkent atirkaljak a fel kernelt azert, hogy egy ujabb hardvert (valamilyen modon) tamogasson.

te azt latod, hogy megjelent egy ujabb hardverhez tamogatas. aki fejleszt (peldaul wolphie es en is), az pedig azt latja, hogy adott esetben ismet megszopta, mert modositania kell a kodon ahhoz, hogy tobb kernel alverzio is tamogatva legyen.

nem vagyok rola meggyozodve, hogy ez igy jo.

- Nem ertem hogyan jon ide a memory/cpu hotplug stb. tamogatasa.

- Igen en is orulok annak hogy fejlodik a linux

- Majd 2.6.1x.x.x.x.x.x verzioban majd ugyis megfixelik, amit most beleraktak a stable kozepebe :)

- Az ilyen valtoztatasoknak koszonhetoen sokkal kesobb lesz hasznalhato az uj kernel tobbi ujitasa akarmilyen disztribucioban.

pl debianban nem veletlenul nem talalod meg az uj kerneleket, ugradelni kene userspace cuccokat hozza. Ugyan van benne tonna ujdonsag, de megsem hasznalhatod ki. Tehat akkor egy ilyen lepes mire jo? Es nemregen megjelent hirhez visszaterve persze nem kell driver api, mert nemkell / majdmimegoldjuk / auditaljuk / csakmitudjukjolmegcsinalni / nemszamithogybreakelnemertamitbreakelhozzamodositjukmertmicsinaljuk

Aztan kiderul, hogy van am userspace fuggoseg is, ugyhogy megsem igaz amit mondtunk, de nembaj, igy jo ez. Megis csak el kene gondolkodni, hogy kene normalis hoszzu tavra kitalalt (pl az adott stable szeriahoz) kernel api :)

Egyebkent meg: Igen EZ hatranya az udevnek.

...ebben mar bent lesz az Open Driver API? :)

"Elmondtak 100x, hogy ok hanyjak bele a feature-t, a disztribucioknak meg a dolgok, hogy stabilizaljanak. Ez a Linux. Nem tetszik? Switch masra."

a vendornak pedig mas dolga sincs, mint a csodalotasan featuregazdag kernelt stabilizalni es rejszolni oromeben. ha ez az egesz jelenlegi helyzet neked, mint (te fogalmaztal) usernek hasznos es nem okoz problemat, akkor nagyon csodalkozom.

egyre kevesebb kulonbseget latok a fo-fo-fo open source majerek (nem csak linux core developereket ertek ez alatt) es a microsoft sokat szidalmazott hozzaallasa kozott ("nem tetszik? monnyal le.").

"Egyebkent is rossz helyen kopogtatsz a sirassal, a megfelelo hely az LKML."

ettol szanalmasabban aligha tudtad volna lezarni ezt a vitat.

> Mer' hogy jon ide az iptables.

Kernelspace userspace kompatibilitasi problemak (mem/cpu hotplug/stb nem erintett ilyen szempontbol)

> Nagyszeru, oruljunk egyutt.

Hurra

> Elmondtak 100x, hogy ok hanyjak bele a feature-t, a disztribucioknak meg a dolgok, hogy stabilizaljanak.

Akkor most miert orulunk? Mert beleraktak egy drivert a kernelbe, amit majd fel ev mulva szallitanak majd a disztribuciok?

Hurra hurra. (Te mondtad, hogy production gepen nem disztrib altal szallitott kernel hasznalni baromsag,)

> Igen, a devfs-nek meg az, hogy nem fejlesztik, es millionyi security es mas hiba van benne. Melyik a jobb?

Ellenben kisebb, gyorsabb, es kevesebb memot eszik. (security infot meg nem tudom honnan vetted, de mint "User" ezt mar csak jol tudod :)

Az udevvel meg semmi bajom, csak nem kell ugy tenni mint ha a linux tokeletes lenne :)

ne itt fudolj, hanem az LKML-en, te msberenc.

hu, ugy latom itt egyeseknek nagyon elszallt a vilagrol alkotott kepzelete. ismered azt a kifejezest, miszerint nem a farok csovalja a kutyat? akkor probald meg alkalmazni a kernel (meg barmi mas) fejlesztesere. te felhasznalo vagy, nem fejleszto, tehat NULLA beleszolasi jogod van abba, hogy azok, akik IRJAK a kodot, hogyan is teszik azt (es persze az is tok mindegy, hogy ez MS vagy vki mas). bekiabalni a palank szelerol meg kb annyit er, mint a kocsmai politizalas, ez meg itt valami portal vagy mi akar lenni ;-). ahogy trey is nagyon helyesen megmondta: ha valami nem tetszik, mondd el azoknak, akik felelnek erte (linux -> LKML). mondjuk ha meg akarsz sporolni magadnak egy nagy flame-t, akkor jobban jarsz, ha elotte utanaolvasol az elotted probalkozoknak ;-).

>> ha valami nem tetszik, mondd el azoknak, akik felelnek erte (linux -> LKML)

v.ö.:

>> jobban jarsz, ha elotte utanaolvasol az elotted probalkozoknak

ismerek azert olyan oss projectet is, ahol feature requestek alapjan es a felhasznalok oromere tortenik a fejlesztes, tehat nem mindenre igaz, hogy akar a MS is fejlesztetne, kb annyi beleszolasod van

nemism. :)

>Nem, de ugy sem, mintha egy hasznalhatatlan valami lenne. :-)

Igy van. Tobbszor emlitettem, hogy aktivan hasznalok linuxot egesz komoly celokra, de ettol meg nem probalom meg magam megnyutatni azzal, hogy devfs megszarabb volt, tehat a linux az igy tokeletes, ahogy van :)

> Erdeklodnek (persze szigoruan, mint lame user a developer-tol), hogy az ``unfixable races'' az mi, ha nem security bug?

Developer ugyan nem vagyok, de kerdezz batran ;)

ttp://www.hup.hu/wiki/index.php/Verseng%C3%A9s

Igen egyben lehet security bug is, de csak specialis esetben.

"ettol meg nem probalom meg magam megnyutatni azzal, hogy devfs megszarabb volt, tehat a linux az igy tokeletes, ahogy van :)"

Egyrészt: abból, h a régebbi "szart" helyettesítették valami jobbal, még nem feltétlen következik az, h tökéletes lenne...

Másrészt: állított egyáltalán akárki is olyasmit, h tökéletes?

en se mondtam, hogy nincs ilyen. csak azt, hogy az max egy gesztus fejlesztok reszerol, nem a felhasznalonak jaro jog (amivel ugy tunik sokan osszekeverik). amugy meg meglepodnel, hogy az MS-nel mennyire veszik figyelembe a felhasznaloik kivansagait. nem jozsika warez windows userrol van szo persze, hanem nagy vallalati felhasznalokrol.

>ha valami nem tetszik, mondd el azoknak, akik felelnek erte (linux -> LKML).

Mondja el mint Te ? Ugye ezt Te magad sem gondoltad komolyan ;) Azt hiszem Neked nem kell bemutatni azt az arroganciat es elitista hozzaallast ami az lkml-en megy.

>jobban jarsz, ha elotte utanaolvasol az elotted probalkozoknak ;-).

Igen errol beszelek, mondhatnank ugy is hogy szarnak a pofon :)

Igen lehet forkolni/jobbat csinalni/elhuzni, de ettol meg a linux kernel nem lesz jobb. Kb 5 fokernelmatyizo meg par ceg dont arrol hogy mi a jo neked.

(Az a jo neked, hogy mire portolod a paxot 2.6.x-re addigra megjelenik a 2.6.x+2 :P)

> Most akkor fejlesztunk vagy nem?

Aki nincsen benne az lkmlbe az nem szamit, mert az ugyis luzer ;)

> Javaslom, hogy nezd at, hogy mi az a race condition [www.google.co.hu]. A race conditiont javitani kell, es szoktak is.

Itt Te barhol azt olvasod, hogy race condition == security bug? Megegyszer leirom User urnak:

A race condition lehet egyben security bug is. Ha legalabb vegigolvastad volna amit te magad kerestel googlebe, akkor lathattad volna, hogy egyaltalan nem biztos hogy security problema a race condition. Nem mintha szepen mutatna a kernelbe'...

> A race conditiont javitani kell, es szoktak is.

Igen ez altalaban igy van mindenfele buggal :-)

> The vendor has released a fix.

Ez pont nem az az unfixable race condition volt ami egyben security bug is. Beguglizod nekem az igazit is? :>

Az az unfixable azota secholekent figyel a kernelbe?

Folosleges magyarazni a hulyeseget :)

Igen = "A devfs eseteben altalaban" - Milyen gyorsan kernel developer lettel itt userbol, de azert az assignment es comparison operators temakort meg tanulgassad kicsit :)

Ja es ha jol tudom veletlenul az udevbe is volt race condition :)

Na joccak

> még nem feltétlen következik az, h tökéletes lenne...

Igen. Akkor legyen mar szabad jeleznie a juzernek hogy ez egy hatrany. Egyesek keptelenek elviselni, ha valaki negativumot mond a linuxrol.

> "Oh yeah, and there are the insolvable race conditions

Most direkt nem latod mit irtam? :))) Megegyszer:

Az az unfixable azota secholekent figyel a kernelbe?

Vagy akkor megint oda lyukadtunk ki hogy race condition = secbug? Dontsd el vegre, hogy akkor mivan, en sehol sem lattam utalast arra, hogy az az unfixable race condition az security bug lenne. Nyugodtan keress ra, hogy devfs lookup vs deadlock, megtalalod az altalad emlitett problemat.

> Oh, jon a szemelyeskedes... mar vartam :-D

En meg azt vartam, hogy nem fogsz erdemben valaszolni, hanem felrebeszelsz, vagy megnagyobb hulyeseget mondasz ;)

> Barmi lehetseges. Csak azt felejted el...

Nem felejtettem el, nem az udevvel van bajom, hanem az udev ilyen szintu turasaval, csak ugylatom ezt elfelejtetted elolvasni meg az elejen, mert az szep, hogy leirod 15x hogy mennyivel faszabb az udev, csak ebbol nem kovetkezik az, hogy az udevet annyira meg kell valtoztatni, hogy userspace breakeles legyen a vege. Hagyd abba a folosleges mellebeszelest :)

Nekem is boven van mit tanulnom, de nem te vagy az az ember akitol kene, folosleges megprobalnod kioktatni, raadasul olyan dologban amiben keptelen vagy bizonyitani az igazad foleg nem.

Hagyd, drogos.

> Elmondtak 100x, hogy ok hanyjak bele a feature-t, a disztribucioknak meg a dolgok, hogy stabilizaljanak. Ez a Linux.

hmmm, azon gondolkodok, hogy ennek lehet egy olyan mellekhatasa, hogy csokken a disztrok szama. Hiszen nem minden csapatnak lesz annyi kapacitasa, hogy stabilizalja a kernelt. Gondolok itt egy Frugalware,bP meretre vagy kisebbre. Hany _aktiv_ fejlesztojuk is van?

Es mennyi eselye lehet annak, hogy erre a stabilizacios munkara egy kulon csoport fog alakulni, akinek a munkajara sok-sok disztro tamaszkodhat?

Vagy ez a stabilizalas nem is vesz el annyi idot, es 1 ember is lazan elvegzi? Bar ahogy egyre nagyobba valik a Linux, egyre tobbet kell vele foglalkozni.

csak gondolkozom..

"te felhasznalo vagy, nem fejleszto, tehat NULLA beleszolasi jogod van abba, hogy azok, akik IRJAK a kodot, hogyan is teszik azt"

aham. szoval a vilagrol alkotott "kepzeletemmel" (barmi is legyen az) az a legfobb baj, hogy nem feltetlenul szimpatikus, hogy a user van a kernelfejlesztokert. miert is? azert, mert a majer open source profetak pontosan ennek az ellenkezojet hirdetik es pontosan ezekert a dolgokert orditjak habzo szajjal hogy igy dogoljon meg a microsoft meg ugy haljon meg minden zart forrasu szoftvereket gyarto ceg (t.i. hogy ok ugy gondoljak a user van oertuk es nem forditva). en nem gondolom, hogy a fejlesztoknek kellene lenniuk a felhasznalokert, hanem azt, amirol szerintem tobbek kozott az open source szol: a fejlesztok a userekkel egyutt, az o velemenyuket is meghallgatva, kozosen oldjak meg a problemakat. sok projekt eseten ez mukodik. a linux eseteben egyre kevesbe.

miert nem megyek az lkml-re? mert en csak egy kis parasztgyerek vagyok, nincs nevem ott, igy aztan hiaba probalnek meg elmondani olyan dolgokat, amiket emlekeim szerint mar elmondtak ott tolem sokkal nagyobb fejek es megis leszartak. szerintem pont neked nem kell ezt magyarazni.

es egyebkent is: ez nem kocsmai hozonges, hanem vita. szakmai vita. ez allitolag egy szakmai portal. ja, hogy nem a microsoftot szidom orrba-szajba?

In article <42.56973@c.hup.hu>, zsirfeka wrote:
> aham. szoval a vilagrol alkotott "kepzeletemmel" (barmi is legyen az) az a
> legfobb baj, hogy nem feltetlenul szimpatikus, hogy a user van a
> kernelfejlesztokert. miert is? azert, mert a majer open source profetak
> pontosan ennek az ellenkezojet hirdetik es pontosan ezekert a dolgokert
> orditjak habzo szajjal hogy igy dogoljon meg a microsoft meg ugy haljon meg
> minden zart forrasu szoftvereket gyarto ceg (t.i. hogy ok ugy gondoljak a
> user van oertuk es nem forditva). en nem gondolom, hogy a fejlesztoknek
> kellene lenniuk a felhasznalokert, hanem azt, amirol szerintem tobbek
> kozott az open source szol: a fejlesztok a userekkel egyutt, az o
> velemenyuket is meghallgatva, kozosen oldjak meg a problemakat. sok projekt
> eseten ez mukodik. a linux eseteben egyre kevesbe.

Ez igy van.

> es egyebkent is: ez nem kocsmai hozonges, hanem vita. szakmai vita. ez
> allitolag egy szakmai portal. ja, hogy nem a microsoftot szidom
> orrba-szajba?

Dehogy szakmai. Ez a trejportal, ahogy o maga is mondta. MS fukkolo,
linuksz elteto.

--
Gabucino

valoban, trey? ne mondd mar. kepzeld, rajtad kivul vagyunk meg paran, akik nem csak egy OS-t hasznalnak es megkockaztatom, hogy szinten vagyunk egy paran, akik kepesek felmerni azt, hogy egy adott feladatra mi a legalkalmasabb rendszer, a korulmenyeket figyelembe veve.

a problema csupan azzal van, hogy itt a hupon a rajongotaborod 99%-a keptelen elviselni, ha valaki negativ kritikat fogalmaz meg a linuxszal szemben (holott ez egy _szakmai_ forum, ahol elvileg lehet vitazni), ellenben a windows (es ugy altalaban a microsoft) agy nelkuli gyalazasa teljes mertekben megengedett (nem, nem cenzurara gondolok, mielott kiforgatod a szavaimat). erdekes modon nem olvastam meg toled olyat, hogy "ocsem, irjal mar a microsoftnak es ott mondd el a problemaidat". pedig te, ahogy tobbszor is emlitetted, otthon vagy windows temakorben is, sot, tobb ilyen rendszert tartasz karban. vagy legalabbis telepitesz.

rendben, fejezzuk be, de engedd meg, hogy idezzek toled:

"Nem, nekem nem okoz problemat. Ha okozna, hasznalnek mast. Nekem - egyesekkel ellentetben, akik szanalmas kis egy operacios rendszeruket toljak minden feladatra - nem okoz lelki torest, ha tobb operacios rendszerrel kell dolgoznom."

vitatkozhatunk azon, ki kezdte a szemelyeskedest, de ennek tenyleg nincs ertelme.

"Senki nem mondta nekik, hogy nekik disztrot kell csinalni. Kellemetlen ha kevesen vannak. De ez nehogy mar a kernel fejlesztok problemaja legyen... :-)"

ennyit a valasztas szabadsagarol.

> Documentation/feature-removal-schedule.txt

Biztos neked a malicsuszos proxyd beleirja mindenbe, hogy security bug. Nekem meg mindig sehonnan sem derult ki, hogy az altalad oly sokat emlegetett problema security bug lenne. (Azert mert nem az)

> Felelossegteljes programozo abbol indul ki, hogy feltetelezi a legrosszabbat.

A felelossegteljes programozo eleve nem ad ki ennyi szutykot a kezebol, mert elore latja a legrosszabbat, megtervezi es nem utolag fixelget nagyon durva hibakat. (Hogy ilyenbol ***** keves van? Igen)

> Igazad van, csak egy deadlock nem sulyos hiba

En ezt nem is allitottam soha.

> ezzel a hozzaallassal szep jovo var rad a szakmadban :-D

Portaluzemelteto, blogiro, 168papiros linukszuzemelteto, mindenhezerto, partyrajaro, fpsjatszo, mindendisztrot kiprobalo, sokszkrinshotkeszito, windozpreinstallspecialist, jocsaladapa, lkmlstilustjolatvevo mighty trey isten most kerneldeveloper is lett vegre es szembehugyozva a szellel probalja megvedeni nemletezo igazat a race conditionrol.

EZ AZ AMI KELL HOZZA, HOGY FASZA SZAKEMBER LEGYEL!

a te es az en es a mi valasztasunk szabadsagarol, hogy olyan disztribuciot hasznaljunk, ami a legjobban megfelel az adott celra (sok disztribucio - nagyobb szabadsag). a te es az en es a mi valasztasunk szabadsagarol, hogy kis disztribuciot is indithassunk (viszonylag keves aktiv fejlesztovel), ha ugy tartja kedvunk. vagy mar nem errol szol ez a dolog? persze nem tiltja senki, hogy csinaljunk ilyen disztribuciot. maximum beledoglik rovid ido alatt. kit erdekel?

egyebkent nem hiszem, hogy a nagy disztribuciok is tapsikolnanak oromukben.

a normalis keretek kozott folytatott vita (esetleg flame :-)) nekem sincs ellenemre, de a ezt a threadet olvasva kialakult egy kep bennem arrol, hogy nalad mit is jelent a vita: hajtogatom a magam igazat, nem baj, hogy husszor megcafoltak, maximum szemelyeskedes lesz a vege es befejezzuk. erre nincs se idegzetem, se idom, ne haragudj.

nem fogyott el, hallom, amint visitva rohog.

lehet, hogy nemcsak linkelni kene orrba-szajba, hanem elolvasni (es ertelmezni) is azt, amit linkelsz, meg amit a vitapartner allit. na mindegy.

> Igy gepeimen a FreeBSD-tol a Windows 2003 Advanced Server-ig bezarolag eleg sok operacios rendszer megtalalhato.

Nincs is olyan, hogy Windows 2003 Advanced Server ;-DD

> Tehat ha wolphie allitja, hogy a race condition nem security bug, akkor alljak vigyazba? :-)

Nem, inkabb guglizzal, mielott teljes biztonsaggal allitasz valamit ami nem igaz. :)

> Mar megint a szemelyeskedes. Elfogyott a cerna, jolprogramozowolphie? Nem birtad sokaig. ;-)

En jol birom idegekkel a flamet, csak vigyorgok inkabb :P

Kinek mi a szemelyeskedes. Nem ismersz, en sem teged, viszont en nem probalom meg eloadni az ultime't szakember dumat magamrol, mert nem lesz valami hiteles. Erre celoztam elozo hozzaszolasommal.

"Es szerinted az a Linux kernel programozok hibaja, hogy a kis disztribuciok nem tudnak embererot tenni a kernel karbantartasa moge?"

nyilvan nem. mindossze rakenyszeritik a disztribuciokeszitoket arra, hogy a szuksegesnel tobb ember foglalkozzon a dologgal.

de igazad van, aki nem birja, dogoljon meg, mert ugye ez a szabadsag.

"A nagy disztribuciok emberei @suse.com, @redhat.com mint ott vannak, es eleg kemenyen fejlesztik a kernelt. Sot eleg kemenyen bele is szolnak a fejlesztesbe."

ezzel en is tisztaban vagyok. ugyanakkor rajtuk kivul is gondolom dolgoznak nehanyan meg egy-egy releas-en.

release, na :-)

"Az okozza a felreertest koztunk, hogy te allandoan programozoi, en meg felhaszanaloi szemmel nezem az egeszet."

ez igy ebben a formaban nem igaz. reszben fejlesztoi, reszben felhasznaloi szemszogbol nezem, es szerintem itt tobbunk neveben is beszelhetek. a gond az, hogy sok es nagy rendszereken nyomjuk, es bizony sok olyan dologba futunk bele nap mint nap ilyen (ertsd: nem feltetlenul fejlesztoi) szinten is, amit adott esetben kenytelenek vagyunk mi magunk fixelni, vagy olyan kenyszermegoldasokat alkalmazni, amikkel kapcsolatban vannak fenntartasok boven, de sokszor nincs mit tenni.

Hi! :D

Így kompletten hozzászólva a threadhez:

ROTFL ;)))

"Es termeszetesen ez csak a Linuxszal van igy. Semmilyen mas OS-sel, hardverrel nincsenek ilyen problemaitok, csak a tetves Linuxszal."

lattal ilyet leirva? mondtam ilyet valaha? nem.

miutan linuxot hasznalunk nagyon sok helyen, nyilvan az aranyok errefele tolodnak. sok-sok evvel ezelott (nem irok majd' egy evtizedet, mert csak jovore lesz 10 eve, hogy belefogtam), de akar csak 1-2 eve a linux meg nem errol szolt, amirol most. ha mindig is ilyen lett volna, nem fajna.

a "FUD"-olasrol (remek kis "geek" divatszo) pedig utoljara (mar tobbszor kifejtettuk, lehet, nem egyertelmuen) ennyit: ha nem lenne itt a sok droid akik tematol es ugy altalaban mindentol fuggetlenul nekiallnak fikazni _barmit_ ami nem linux/debian/open source/GPL, akkor esetleg mi is visszafogottabbak lennenk.

ha nem lenne ez az iszonyatos, egyre novekvo arrogancia amivel az onjelolt open source profetak viszonyulnak mindenhez, ami az o latokorukbe/vilagnezetukbe nem fer bele, akkor esetleg mi is visszafogottabbak lennenk.

ha egy normalisan indulo vitaban (nem flame-ben) nem jelennenek meg egybol a mindenhol microsoft-berenceket vizionalo, a szabadsagot felreertelmezo ("szabadda teszlek, akar tetszik, akar nem") droidok, akkor esetleg mi is visszafogottabbak lennenk.

tapasztalataim szerint az altalanos felfogas ezekben a korokben (nem csak itt a hupon, hanem sok helyen) ez: a linux jo, jobb, legjobb. amit a maroknyi core developer mond, az szentiras, ugy van jol, mindenki kussoljon, mert ok tudjak, hogy mit csinalnak, kisgyerek ne pofazzal bele, mert hogy jossz ahhoz, hogy beleszolj, ki vagy te, nem is ertesz hozza (esetleg akkor is, ha a neved alan cox). ha ez ellen felemeled a szavad, akkor luzer, nyomorult ostoba paraszt vagy, nem szakember.

a mar emlitett, mindenhol ms-berenceket vizionalo userek nem "FUD"-olnak? az nem zavar? nyilvan nem, mivel ok eletukben lattak egy windows-t meg egy office-t es ez alapjan ki merik jelenteni teljes bizonyossaggal, hogy minden, amit az MS csinal, ***** es ez igy is marad, mig vilag a vilag. microsoft jon elo akkor is, amikor a temahoz semmi koze, de nem baj, mert kell egy kozellenseg.

ha megemlitesz ellenpeldakat vagy megprobalsz ramutatni erre a visszas helyzetre, akkor berenc vagy, raadasul nem tudod, hogy mirol beszelsz.

dontsd el, hogy a ketto kozul melyik a "FUD".

> Mondja el mint Te ? Ugye ezt Te magad sem gondoltad komolyan ;) Azt hiszem Neked nem kell bemutatni azt az

> arroganciat es elitista hozzaallast ami az lkml-en megy.

nem veletlenul irtam zarojelben a linux->LKML peldat, nyilvan az elotte levo altalanos megallapitas volt a lenyeg, ami remelem vilagos, hogy miert van ugy. az, hogy az LKML kozonsege milyen, az egy kulon mise, de tok mindegy, mert ez van, ezt kell szeretni (vagy nem, lehet valtani).

> Az a jo neked, hogy mire portolod a paxot 2.6.x-re addigra megjelenik a 2.6.x+2 :P

akkor most ugy latszik rekorddontesi kiserletnek lehetsz szemtanuja, mert X+3 lesz belole ;-)

> En csak egyben remenykedem. Hogy programozo letedre nem a devfs-hez fejlesztesz.

halott kodrol jot vagy semmit.

> A race-ekkel meg ne torodj. Felejtsd el oket. Ha figyelnel rajuk, akkor csak zavarna a munkadat :-D

Na ez nem vicces, mert ez a 2.6 fejlesztesi modell eppen, majd Greg megfixalja a -stable-stable-stable-really-stable verzioba, mi csak belevagjuk oszt jovan. Nezdma' pont a 2.6.14.2-be is fixalt egyet. Na jovan szarjunk ra mi is, Gregnek meg kuldunk 2 sort :)

nem vagyok rola meggyozodve, hogy azok a hozzaszolasok valoban a cikk, es nem ellened szoltak. ezt nektek kell tudnotok, nem nekem kell eldontenem.

azert remelem erted, hogy en mirol beszeltem az elobb.

Hmm... Az ötödik bekezdésed szerintem nem csak linux-specifikus. Elképzeltem, h mi történne, ha nekiállnék mondjuk Theonak megmagyarázni, h nem igazán jó az, ahogy csinálják a dolgokat... (;

> Elképzeltem, h mi történne, ha nekiállnék mondjuk Theonak megmagyarázni,

Ez itt a szimulacios gyakorlat kicsibe, csak most portalmester van Theo helyett :)

> akkor most ugy latszik rekorddontesi kiserletnek lehetsz szemtanuja, mert X+3 lesz belole ;-)

Meritthupozolaze' :)

> (aztan lehet csurni-csavarni, hogy az esetek 10%-ban nem biztos, hogy az)

Umm, en 8.47%-ra saccolom, de lehet tevedek.

> az a legfobb baj, hogy nem feltetlenul szimpatikus, hogy a user van a kernelfejlesztokert.

ill.

> a majer open source profetak pontosan ennek az ellenkezojet hirdetik

welcome to the world of real (asszem matrix, remelem nem szurtam el ;-). ha eddig nem tunt volna fel meg, ami szamit a vilagban az az, amit megteszel, nem pedig az, amit kimondasz. vagy ahogy regen az uttoroknek tanitottak: a tettek beszelnek. az LKML mostansag egy eleg extrem pelda (sajnos vagy nem, nezopont kerdese), de ez van, es mint mondtam, NULLA eselyed van megvaltoztatni (ja, es mielott felreertenel, en nem azt mondom, ami nekem tetszik, hanem csak azt, amit latok, vagyis megfigyelest, nem velemenyt). szoval szep ideal, amikor a sok kis pajtas kez a kezben nekiindul megvaltani a vilagot, de a valosagban nem ez megy, helyette vannak emberek ill. cegek, akik jo penzert uzik a hobbijukat, es mindezt ugy, ahogy nekik a legjobb. ami persze nem feltetlenul a legjobb neked, a felhasznalonak. amugy azert ezen nem kell annyit csodalkozni, az elet tele van mashol is olyan helyzetekkel, amikor ket rossz kozul kell a kisebbiket kivalasztani, az LKML eseten ez a regi fejlesztesi modell feladasahoz vezetett, mert a fejlesztoknek (es bizony gyakran a felhasznaloknak is) a nagyobb rossz az volt, hogy bizonyos fejlesztesek akar eveket is varakoztak, mire bekerultek a kernelbe (vagy az egyes disztrok kernelei kezdtek el divergalni, ami hozta a sajat problemait). az, hogy a valasztott uj fejlesztesi modell hosszu tavon jobb/rosszabb-e mint a regi, majd kiderul. az biztos, hogy iszonyu sebessegre kapcsoltak a sracok, le a kalappal elottuk (mar tobb, mint egy eve atlag 10MB/ho patch kerul be es az egesz meg mindig nem dolt ossze).

a kocsmas pelda amugy arra volt, hogy te is meg masok is panaszkodtok, hogy igy meg ugy ***** a rendszer, de azert semmit sem tesztek, hogy megvaltozzon (pl. lehet panaszkodni az LKML-en, azert nem mindenki onfeju). pontosan ugy, ahogy a kocsmai politizalas megy. es abban is nagy a hasonlosag, hogy azok 'tudjak' a legjobban a kernelfejlesztest, akik meg soha nem csinaltak. ja, es nem attol lesz szakmai vita vmi, hogy mit fikaznak benne (MS-t vagy a linuxot vagy mast), hanem a resztvevok hozzaallasatol es hozzaertesetol. ami ebben a szalban lefutott idaig, azt a hunger valaszolta meg a legjobban ;-).

In article <42.57024@c.hup.hu>, zsirfeka wrote:
>
> [...]
>

Ez igy jo ahogy van. Teljesen egyetertek.

--
Gabucino

rotfl :)

lol

- támogatás a Marvell SATA kontrollekhez (mit nem adtam volna ezért két héttel ezelőtt :-), hasznos lehet többek közt HP Proliant 150 tulajdonosoknak (aar81xx))

Ez kellemes lesz, a Supermicrónak van (itthon is kapható) 8 csatornás, 64 bit PCI-os SATA vezérlőja, lehet építeni óccsított fileszervert. :)