A lényeg (idézet hupról, de tényleg ezt írják):
"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."
-1 a kernelnek :-)
--
Zizi
"How do you kill one, who has no life?"
_______________________________________________________
linux-flame lista - linux...@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux-flame
> -1 a kernelnek :-)
Mondjuk durva, hogy ilyen érveken múlik a kernel fejlődése :/
--
Dr. Szöszi
http://silver.rulez.org
Sok minusz lesz mar :)
Hogy lehetne ezt megoldani? AM orrara koppintani? Megreformalni a
patch elfogadast, amit annyian szidtak mar? A kernellel kapcsolatban
mart nem is hallani az utobbi idoben, minthogy aki javitja,
vesszofutast kell tulelnie, hogy bekeruljon a valtoztatasa a kernelbe.
En csak kivulallo, szemleleodo vagyok, de eddig egyre tobb a
nem-dicsoites a hivatalos kernel vonalon, sajnos.
--
Tamas
Szeirntem az lenne a megoldás, ha Linus meg a többi őskövület
kiszállna a kernel feljesztéséből.
Tudom, hogy furcsán fog hangzani, de szerintem ma az informatika nem
ugyanaz, mint majd' 20 évvel ezelőtt, amikor a Linux kernel
fejlesztése elkezdődött. Sokminden változott, és pl. számomra az,
ahogy a kernel forráskódja, a részek közötti tökéletes
összehangolatlanság kinéz finoman szólva archaikusnak tűnik.
Hangsúlyozom, hogy egyáltalán nem tudnék jobbat alkotni, és csak a
saját véleményemet mondtam el, ami nem feltétlenül egyezik sem mások
véleményével, sem azzal, amit az egyetemen tanultam.
> A kernellel kapcsolatban
> mart nem is hallani az utobbi idoben, minthogy aki javitja,
> vesszofutast kell tulelnie, hogy bekeruljon a valtoztatasa a kernelbe.
Ez viszont főleg azért néz ki így, mert akinek a patch-e belekerül, az
nem hangoskodik.
> En csak kivulallo, szemleleodo vagyok, de eddig egyre tobb a
> nem-dicsoites a hivatalos kernel vonalon, sajnos.
A lehetőség meglenne (fork) és ehhez igazából nem egy jó programozó
kellene, hanem egy jó vezető. Ilyenje viszont most nem nagyon van
ennek a területnek.
--
Zizi
"How do you kill one, who has no life?"
Érthető és megmagyarázható. Kíváncsi leszek egyébként a RHEL6-ra :-)
--
Zizi
"How do you kill one, who has no life?"
> Érthető és megmagyarázható. Kíváncsi leszek egyébként a RHEL6-ra :-)
Benne pontosan mire? :)
Hosszú távon (3-4 év) szerintem meg fog jelenni egy enterprise kernel,
ami függetlenebb lesz.
--
Dr. Szöszi
http://silver.rulez.org
Arra, hogy mennyi dolog fog kihullani belőle amiatt, mert supportálhatatlan.
> Hosszú távon (3-4 év) szerintem meg fog jelenni egy enterprise kernel,
> ami függetlenebb lesz.
Ez saját kútfő, vagy láttál/hallottál valamilyen utalást erre valahol?
Persze csak ha nem titok. Ez szerintem nagyon jó ötlet lenne, pontosan
az, amire nekem szükségem lenne.
--
Zizi
"How do you kill one, who has no life?"
> Arra, hogy mennyi dolog fog kihullani belőle amiatt, mert supportálhatatlan.
Na igen, ez várható.
> Ez saját kútfő, vagy láttál/hallottál valamilyen utalást erre valahol?
> Persze csak ha nem titok. Ez szerintem nagyon jó ötlet lenne, pontosan
> az, amire nekem szükségem lenne.
Mondjuk azt, hogy azok a vörös kalapot viselő verebek, akikkel a múlt
héten volt szerencsém Bécsben összefutni, érdekes dolgokat csiripeltek :)
Érik már, hogy beugorj egy kávéra ;)
--
Dr. Szöszi
http://silver.rulez.org
Nekem is az jutott eszembe multkori toprengesemben, hogy ezek folott az
emberek folott atlepett az ido es a fejlodes, es nagyon gyorsan el
kellene huzniuk pihenni, mert igy nagyon rovid idon belul valamelyik ceg
forkol egy sajat kernelt (vagy kiadja a nem publikus kernelet).
A kernelfejlesztes iranyitasa nem programozoi munka, kell par jol
kepzett tervezo, par szervezo, es utana barmalyik kinai/indiai hacker
osszedobja a kodot, es olyan mukodesi forma, pl alapitvany, ami kelloen
tokeeros ahhoz, hogy eltartsa azt a par embert, aki vezenyel, ne holmi
redhatos es hasonlo managgak osszak a eszet arrol, hogy mi keruljon a
kernelbe.
>
> Hangsúlyozom, hogy egyáltalán nem tudnék jobbat alkotni, és csak a
> saját véleményemet mondtam el, ami nem feltétlenül egyezik sem mások
> véleményével, sem azzal, amit az egyetemen tanultam.
>
Ezt szerintem felesleges irnod, aki az ilyen jellegu felvetesekre a
csinalj jobbat jellegu sztereotip baromsagot nyogi be, az csak magarol
allit ki szegenysegi bizonyitvanyt.
>> A kernellel kapcsolatban
>> mart nem is hallani az utobbi idoben, minthogy aki javitja,
>> vesszofutast kell tulelnie, hogy bekeruljon a valtoztatasa a kernelbe.
>
> Ez viszont főleg azért néz ki így, mert akinek a patch-e belekerül, az
> nem hangoskodik.
>
Morton helyzete sem irigylesre melto, mert o az utkozo a plebs remalmai
es a valosag kozott :) Es sorba hagyjak ott a tobbiek, akikre szukseg
lenne, mert nekem eros a gyanum, hogy mar regen nem linuson vagy alan
cox vallan nyugszik a kernelfejlesztes kritikus resze. Az ujabb es ujabb
marhasagok bevezetese ugyanugy kellemesebb es jobb marketinggel jaro
feladat, mint a sokezer hiba javitgatasa.
--
Gabor HALASZ <hala...@freemail.hu>
> cox vallan nyugszik a kernelfejlesztes kritikus resze. Az ujabb es ujabb
> marhasagok bevezetese ugyanugy kellemesebb es jobb marketinggel jaro
> feladat, mint a sokezer hiba javitgatasa.
Asszem tegnap küldtem egy blogrészletet, ahol a rh kernelek
nevelgetéséről van szó. Lehet, hogy sok szutykot tol(at)nak bele a
kernelbe a nagy, pénzes cégek, de utána kőkeményen kiszórják a
hulladékot belőle, ld. 3 havi bugmentesítés.
--
Dr. Szöszi
http://silver.rulez.org
> On 6/22/07, tamas gervai <gthre...@gmail.com> wrote:
>> Hogy lehetne ezt megoldani? AM orrara koppintani? Megreformalni a
>> patch elfogadast, amit annyian szidtak mar?
>
> Szeirntem az lenne a megoldás, ha Linus meg a többi őskövület
> kiszállna a kernel feljesztéséből.
>
> Tudom, hogy furcsán fog hangzani, de szerintem ma az informatika nem
> ugyanaz, mint majd' 20 évvel ezelőtt, amikor a Linux kernel
> fejlesztése elkezdődött. Sokminden változott, és pl. számomra az,
> ahogy a kernel forráskódja, a részek közötti tökéletes
> összehangolatlanság kinéz finoman szólva archaikusnak tűnik.
Összehangoltságot csak akkor lehet teremteni, ha azt mondják a
fejlesztők, hogy "most leállunk új feature-ökkel és fél évig csak a
jelenlegi cuccot tesszük rendbe". Gondolj bele, a 2.6.22-rc5-be (!) egy
új architektúra(!) került bele, de 2.6.22-rc1-ben új firewire stack is
került az új wireless stack mellé: egyszerűen túl sok újdonság kerül be,
amit képtelenség stabilizálni. Ezt viszont nyilván nem fogják megtenni,
mert a "for fun" fejlesztők ilyet nem csinálnak (ez nem "for fun" meló),
a fizetett fejlesztőket meg részben pont az új feature-ökért fizetik.
Szerintem nem az a baj, hogy "őskövületek" vezetik a projektet, hanem
az, hogy ugyanazt a kernelt akarják futtatni a telefon/MP3-lejátszó
jellegű beágyazott rendszereken, a desktopon, a webszervereken és a 4096
processzoros szuperszámítógépeken. A másik probléma az, hogy a vásárlók
is szeretnék néha a legújabb feature-ök egy részét. Ebből jön elő az a
probléma, amit pl. ez a cikk
(http://lwn.net/SubscriberLink/239036/90d0501a325536d5) is taglal, hogy
"stabil" enterprise 2.6.16-os kernelbe 2.6.20-ból backportolnak vissza
cuccokat.
A nem-programozók meg általában nincsenek tisztában, hogy a kernel (vagy
bármely ekkora szoftver) részei nem függetlenek egymástól. Nem olyan
egyszerű a dolog, hogy előveszem a file-okat a hárommal későbbi
változatból és akkor az működni fog: időnként változik a belső
infrastruktúra és akkor borul ez a módszer. Nálunk is az van, hogy a
megrendelő nem az összes javítást akarja, hanem csak annak a két hibának
a javítását, ami zavarja, viszont a hárommal korábbi verzióban -
ilyenkor lehet trükközni a ClearCase-zel, hogy legyen valami megoldás.
[...]
> A lehetőség meglenne (fork) és ehhez igazából nem egy jó programozó
> kellene, hanem egy jó vezető. Ilyenje viszont most nem nagyon van
> ennek a területnek.
Nagyon sok programozó kellene: a 2.6.21-be 842 fejlesztő kódja került
be.
Bye,NAR
--
"Beware of bugs in the above code; I have only proved it correct, not
tried it."
Majd a jövő héten, most nem igazán vagyok a közelben :-)
--
Zizi
"How do you kill one, who has no life?"
> Mezei Zoltan wrote:
>> On 6/22/07, tamas gervai <gthre...@gmail.com> wrote:
>>> Hogy lehetne ezt megoldani? AM orrara koppintani? Megreformalni a
>>> patch elfogadast, amit annyian szidtak mar?
>>
>> Szeirntem az lenne a megoldás, ha Linus meg a többi őskövület
>> kiszállna a kernel feljesztéséből.
>>
> Nekem is az jutott eszembe multkori toprengesemben, hogy ezek folott az
> emberek folott atlepett az ido es a fejlodes, es nagyon gyorsan el
> kellene huzniuk pihenni, mert igy nagyon rovid idon belul valamelyik ceg
> forkol egy sajat kernelt (vagy kiadja a nem publikus kernelet).
> A kernelfejlesztes iranyitasa nem programozoi munka, kell par jol
> kepzett tervezo, par szervezo, es utana barmalyik kinai/indiai hacker
> osszedobja a kodot,
Te még nem láttál közelről indiai programozót, ugye?
Bye,NAR
--
"Beware of bugs in the above code; I have only proved it correct, not
tried it."
Én igen, konkrétan indiait. Tökéletesen, pontosan a terveknek
megfelelően végrehajtotta a programozási feladatot. A tervben volt
egy-két hiba, azokat is tökéletesen végrehajtotta. Nem gondolkodott.
Ugye hogy mennyire más stílust igényel ilyen környezetben/feltételek
mellett programozni, mint 1991-ben?
--
Zizi
"How do you kill one, who has no life?"
Ilyen szempontból pl. a solaris kernele sokkal jobb. Nagyon ritkán
változik benne az egyes részei közötti csatolófelület. Állítólag -
mert ezt sajnos nem nagyon ismerem.
> > A lehetőség meglenne (fork) és ehhez igazából nem egy jó programozó
> > kellene, hanem egy jó vezető. Ilyenje viszont most nem nagyon van
> > ennek a területnek.
> Nagyon sok programozó kellene: a 2.6.21-be 842 fejlesztő kódja került
> be.
Egy karizmatikus, jó vezető magához tudja csábítani azt a 842
fejlesztőt. Szerintem.
--
Zizi
"How do you kill one, who has no life?"
> Ezzel a felevel pont annyi kart okoznak, mint amennyi hasznot remelnek.
> Eloszor tervezunk, utana implementalun, javitjuk a teszteles soran
> felmerulo bugokat, kiadjuk, majd backportoljuk a userek altal bekuldott
> bugokat, ha ebbol a tervezunk es a teszteljuk reszt kihagyjuk, es csak a
Nem biztos, hogy értelek. Anno amikor a Linuxszal elkezdtem foglalkozni,
akkor azt mondták az okosok, hogy van egy csomó minden benne, amire
nekem nincs szükségem vagy nem teljesen jó, legfeljebb majd kihagyom.
Miért baj az, hogy X vagy Y cég ráérő idejében fizet Z db fejlesztőt,
akik valamit kitalálnak, lekódolják, comittolják, majd aztán akinek nem
tetszik, kihagyja vagy megjavítja? Jahogy ez a stabil kernel része lesz?
Ez már legyen a branch fjének a baja...
> es a redhat mar tul nagy es tulsagosan a supportalasbol elo ceg ahhoz,
> hogy erdemi es ertekes fejlesztest vegezzen, ebben ne is remenykedj.
Sorolom: GFS, GFS2, Cluster Suite, Xen. Ezekbe pl. nem kis fejlesztést
tolt a RH.
> Vegul: te is mondtad mar (ha burkoltan is) az enterprise linux csak
> abban kulonbozik, hogy van valaki, aki egy rahedli penzert megmondja
> azt, ami kimaradt a dokumentaciobol.
Nem emlékszem arra, hogy ilyet írtam volna. Részben igaz, de közel sem
ez a teljes kép.
Telefonálni is rühellek, az SMS-ezésről nem is szólva, nem fogok
nagyon skype-olni... Ventrillo, az a jó egy-egy Gruul ölés közben :-p
>> Mondjuk azt, hogy azok a vörös kalapot visel? verebek, akikkel a múlt
>> héten volt szerencsém Bécsben összefutni, érdekes dolgokat csiripeltek :)
>> Érik már, hogy beugorj egy kávéra ;)
>
> Majd a jöv? héten, most nem igazán vagyok a közelben :-)
Az csak jo, igy skypeon kell szervezni (kavet mindenki keszit maganak) :)
--
Udv, Sandor
Legfejlebb az allatkertben fog kodolni, kozel a tigrisveremhez, hogy
legyen nemi motivacio :)
De gondolom erted, mit akarok mondani, megfelelo tervezes es
dokumentalas eseten semmi szukseg arra, hogy egyes emberek fejbol tudjak
a fel kernelt, hogy bele tudjak kalapalni a fejleszteseket, azt pedig,
hogy milyen utemezo dolgozzon kernelben, ne holmi flamewar dontse el,
hanem uljon ossze par programtervezo, es az aktualis helyzet es a
felmerulo alternativak elemzese utan dontson, es ugy dontson, hogy azt a
dontest 4-5 evig ne kelljen megvaltoztatni. Ezek utan szinte mindegy, ki
kodol, ha a gcc le tudja forditani.
--
Gabor HALASZ <hala...@freemail.hu>
--
Gabor HALASZ <hala...@freemail.hu>
>
> Összehangoltságot csak akkor lehet teremteni, ha azt mondják a
> fejlesztők, hogy "most leállunk új feature-ökkel és fél évig csak a
> jelenlegi cuccot tesszük rendbe". Gondolj bele, a 2.6.22-rc5-be (!) egy
> új architektúra(!) került bele, de 2.6.22-rc1-ben új firewire stack is
> került az új wireless stack mellé: egyszerűen túl sok újdonság kerül be,
> amit képtelenség stabilizálni.
Erdekes, en is ilyeneket szoktam itt osszehordani :)
> Ezt viszont nyilván nem fogják megtenni,
> mert a "for fun" fejlesztők ilyet nem csinálnak (ez nem "for fun" meló),
> a fizetett fejlesztőket meg részben pont az új feature-ökért fizetik.
Speciel ezek a latszolag for fun fejlesztok a nagy cegek, pl a redhate
az uj firewire kod, ha nem tevedek. A nagy cegeket pontosan ugyanazok a
marketingszempontok iranyitjak, mint a tobbit (ujabb, szebb, jobb cimkek
ragasztgatasa), ugyanugy a hetfo reggeli meetingen dontenek a managgak,
semmi ertelmes fejlesztest nem lehet toluk varni.
>
> Szerintem nem az a baj, hogy "őskövületek" vezetik a projektet, hanem
> az, hogy ugyanazt a kernelt akarják futtatni a telefon/MP3-lejátszó
> jellegű beágyazott rendszereken, a desktopon, a webszervereken és a 4096
> processzoros szuperszámítógépeken.
Ez szinten azoknak a nagy cegeknek a celkituzese, akiktol sokan a
megvaltast varjak es istenitik, pl buguntu, redhat, stb...
> A másik probléma az, hogy a vásárlók
> is szeretnék néha a legújabb feature-ök egy részét.
Ketlem, hogy az enterprise felhasznalot ilyesmi motivalna.
>
> Nagyon sok programozó kellene: a 2.6.21-be 842 fejlesztő kódja került
> be.
Az iq es a sokasag aranya :) Szerintem a tizedere sem lenne szukseg, ha
terveznenek, es nem adhoc ganyolnanak.
--
Gabor HALASZ <hala...@freemail.hu>
> azt pedig, hogy milyen utemezo dolgozzon kernelben, ne holmi flamewar
> dontse el, hanem uljon ossze par programtervezo, es az aktualis
> helyzet es a felmerulo alternativak elemzese utan dontson, es ugy
> dontson,
Szerinted ha összeül egy ilyen kérdés megvitatására pár programtervező,
az nem eredményez flamewart? Legfeljebb nem levelezőlistán.
--
Friczy
'Death is not a bug, it's a feature'
Az indiai programozokat legyszives ezentul ne emlegessuk egyutt
tisztesseges emberekkel. Nem azok.
--
Tamas
Érdemes megnézni ezt:
http://en.wikipedia.org/wiki/Strategy_pattern
"The strategy pattern is useful for situations where it is necessary
to dynamically swap the algorithms used in an application."
Vagy ezt:
http://en.wikipedia.org/wiki/Visitor_pattern
"A practical result of this separation is the ability to add new
operations to existing object structures without modifying those
structures."
Ezek arról szólnak, hogy hogy lehet megcsinálni egy programban azt,
hogy az egyes darabkái cserélhetőek legyenek. Van még pár ilyen
(template method pl.). Ezeknek a tudatos alkalmazásával megoldható az,
hogy beleférjen a kernelbe hatféle ütemező, akár futásidejű, akár
indításkori, akár fordítás közbeni váltási lehetőséggel, igény
szerint.
Csak Linus egyszer azt mondta, hogy a design patternek hülyeségek.
--
Zizi
"How do you kill one, who has no life?"
Ezért nem programozóra van szükség, hanem szervezőre :-p
--
Zizi
"How do you kill one, who has no life?"
> Csak Linus egyszer azt mondta, hogy a design patternek hülyeségek.
Jol emlekszem, hogy Linust meg lehet gyozni, de leszavazni nem? :)
--
Tamas
Most nem olvasom el a fentieket, de en eddig sem lattam ennek semmilyen
muszaki akadajat. Lehet layereket hasznalni (persze esszel, nem ugy,
ahogyan most csinaljak), lehet modularis kodot irni, stb..stb..stb..de
barmennyit is beszelunk, a lenyeg mindig ugyanaz: tervezni, tervezni,
tervezni.
> Csak Linus egyszer azt mondta, hogy a design patternek hülyeségek.
Kenytelen hulyeseget beszelni, mert kulonben magat kellene szidnia elso
sorban, es akkor odalenne a opensourceisten statusza, hiszen ha megnezed
az atlaglinuxuser hozzaallasat az ilyesmihez, nem sokban kulonbozik a
fideszesek vezeruk iranyaba mutatott attitudjeitol.
--
Gabor HALASZ <hala...@freemail.hu>
Lehet. Én biztosan nem vagyok annyira jó, hogy meggyőzzem, de ahhoz
elég jó vagyok, hogy a véleményemmel spammeljem a linux-flame listát
:-p
--
Zizi
"How do you kill one, who has no life?"
> Egy karizmatikus, jó vezető magához tudja csábítani azt a 842
> fejlesztőt. Szerintem.
Ja, jásd még http://en.wikipedia.org/wiki/Jim_Jones
--
Best regards,
Csibra Gergo mailto:ge...@csibra.hu
Ezzel mit is akartal mondani?
--
Gabor HALASZ <hala...@freemail.hu>
> Az indiai programozokat legyszives ezentul ne emlegessuk egyutt
> tisztesseges emberekkel. Nem azok.
Ha valakik messze vannak akkor mar lehet altalanositani?
Volt harom indiai gyakornokom, mindharom ertelmes volt (nem meglepo,
az IITkrol szedtuk oket), egy nagyon rendes ("tisztesseges") volt,
ketto meg valoban egy kicsit fura :) De oket sem neveznem
tisztessegtelennek, csak eppen specialis szurore volt szukseg a
szavaik/tetteik ertelmezesehez (meg az itt elhangzott "nem
gondolkodtak" kitetellel ellentetben inkabb csak a sajat maguk
szempontjat tartottak az egyetlen jonak*, de ez az IITn fejukbeszallt
dicsosegnek koszonheto, nem altalanos indiai vonas) :)
Nabumm, nem ok az egyetlenek (pl jo par brazillal dolgoztam akik ha
azt mondtak "holnap kuldom", azt jelentette hogy "szolj ujra 1-2 honap
mulva mert meg neki sem kezdtem"), fogadjunk hogy nekik is furak
vagyunk mi magunk is.
*: az elitkepzokbol kikerulo franciak is altalaban nagyon jok ebben a
"hulye mindenki csak en vagyok az okos" jatekban, de az IITsek
kenterbe verik oket
Tessek, szidlak hogy altalanositasz, aztan IITsekrol meg francia
elitiskolasokrol beszelek :) De nem az en hibam, define:iitian a
guglin, ok maguk nevezik igy magukat.
--
Udv, Sandor
Akkor úgy fogalmazok, hogy az indiai programozók tudják, hogy mik ezek
és tudják alkalmazni őket. Csak nem mondják nekik, hogy alkalmazzák
őket, így nem is teszik.
--
Zizi
"How do you kill one, who has no life?"
> Ezzel mit is akartal mondani?
Sajnos igen sok indiai programozoval dolgozom, latom mit muveltek
"programozas" cimen es ilyenkor mindig a kinhalal, es kulonbozo
kinzasok jutnak eszembe. Minden hibat elkovetnek, amit programozo
elkovethet. Semmi mentseguk nincs. Komolyen elzavarnam oket, es soha
tobbet nem engednem szamitogep kozelebe oket, es ha latnad mit
"programoznak" ossze, szeirntem te is igy tennel.
--
Tamas
k-atti-
> Ha valakik messze vannak akkor mar lehet altalanositani?
additinal info: indiai cegnel dolgozom :)
--
Tamas
Ez kod?! :) Java-ban programozni, basic syntaxissal :) Annok kollega
kerdezte, milyen fejlesztokornyezetuk van? notepad .... anyad! ;-)
> Én speciel nem indiaiakkal szemben is éreztem ilyet többször is :) .
Nekem ennyire durva traumatikus elmenyem, mint az indiaiakkal SOHA nem
volt meg. De a mentalitasuk is 'fura' , de amit kodolasban muvelnek,
azt soha nem is kepzeltem volna, hogy lehet.
--
Tamas
Jol van, latom, a szo mar megy. Most forditsd arra az idodet,
hogy megertsd, mit is jelent :)))
--
Udvozlettel
Zsiga
A Solaris kernel egyreszt sokkal regebbi, masreszt kozvetlen UNIX gyokerei
vannak, tehat ez nem egy tul jo osszehasonlitasi alap ;) Amugy ki tudja,
most hogy "jobb Linuxot csinalunk a Solaris-bol mint a Linux", meg ugye az
OpenSolaris community-vel is felig-meddig az a celja a Sun-nak, hogy
Solaris-okba mehessen a sok community altal fejlesztett cucc: lehet itt is
fel fog lepni minosegi romlas ezek miatt.
En kicsit azt is erzem problemanak, hogy a "nep" hosszaszokott hogy a gep az
igenis "fagy" idonkent (unokatesomat lattam 15 percenkent windows-t
rebootolni es kijelentette hogy ot nem zavajra: "megszoktam, ilyen a
technika"). Viszont ujdonsag az kell, mert azzal lehet eladni. Szoval nem
egyszeru, most lehet egy atomstabil de sok ujabb dolgot nem tamogato
software, nem vagyok biztos benne, hogy uzletileg jobban menne nekik, mint a
masik "oldal".
Na persze, megint kicsit osszekocoltam a dolgokat: mert kisse kevertem a
"nep"-et (mint home user stb) az "Enterprise" kivanalmakkal (amirol szo volt
a thread-ben erdendoen, ha jol remlik), dehat azert vmi igazsag csak vagyon
benne meg igy is ...
--
- Gábor
Nem, de hogy mashol is vannak balfacanok, nem menti fel az indiaiakat.
Lattal te mar indiai kodot? Szeirntem nem.
Nem kell ehhez indiaba menni...A debian fele oskovulet pam csomagban van
egy idetlen patch, ami az include-ot valositja meg valami formedveny
gany modon, aminek a legszebb a vege: a funkcio egy return retval
jellegu sorral vegzodik, elotte egy case-es szerkezet van, emberunknek
ki kellett lepni a case-bol egy degeneralt felig megvalositott rekurzio
vegen, amit nem a return retval sorral oldott meg, hanem odatett egy
labelt a return ele majd egy a case-bol egy goto-val odaugrik :-D
--
Gabor HALASZ <hala...@freemail.hu>
>> > Az indiai programozokat legyszives ezentul ne emlegessuk egyutt
>> > tisztesseges emberekkel. Nem azok.
>
>> Ezzel mit is akartal mondani?
>
> Sajnos igen sok indiai programozoval dolgozom, latom mit muveltek
> "programozas" cimen es ilyenkor mindig a kinhalal, es kulonbozo
Ez viszont nem tisztesseg dolga, hanem egyszeruen annak a
kovetkezmenye hogy az indiai szoftverszovetseg (amelyik mindig vedi a
munder becsuletet) sajat bevallasa szerint a frissen vegzett
\"szoftvermernokok\" haromnegyede nem kepes egy hotliner helyet
betoltesere sem. (most ez esik a guglim ala: As per the Nasscom
McKinsey report, the skills and quality of the workforce need to be
improved, since only 25 per cent of technical graduates and 10-15 per
cent of general college graduates are suitable for employment in the
offshore IT and BPO industries respectively.
http://www.blonnet.com/ew/2007/01/22/stories/2007012200100300.htm)
--
Udv, Sandor
--
Udv, Sandor
>> > Az indiai programozokat legyszives ezentul ne emlegessuk egyutt
>> > tisztesseges emberekkel. Nem azok.
>
>> Ha valakik messze vannak akkor mar lehet altalanositani?
>
> additinal info: indiai cegnel dolgozom :)
Arcelor? :-D
(lehet hogy arrafele nem egyertelmu a vicc: az arcelor nevu mammut
acelceget felvasarolta egy indiai srac, a mittal bacsi)
--
Udv, Sandor
Igen, tudomasul kell venni, hogy ha a RollsRoycebol annyit akarnak
eladni, mint Suzukibol, akkor a megvalosulas idejere a pont olyan lessz
a Rolls minosege, mint a Suzukie.
Igazan azt nem ertem, a Sunt mi motivalja erre (illetve tippem az van:
nem szalad a szeker es a managgaknak fingjuk nincsen arrol, hogy mit is
kellene csinalni, ezert sorban talaljak ki a nagyobbnal nagyobb
marhasagokat, hasonloan a mobilszolgaltatok managgaihoz)
--
Gabor HALASZ <hala...@freemail.hu>
Miert is? Mintha a szoftvernel nem lenne darabonkenti eloallitasi koltseg,
szemben az autoval...
Szo
--
Any honest declaration for peace must be an enumeration of
the sacrifices one is prepared to make for its preservation.
Werner Heisenberg
Csak az ugyvedem jelenleteben nyilatkozom, de mivel az nincs, ezert
nem nyilatkozom :-)
Azert ennel kicsit masabb a helyzet. Nem is igeny a jo munka, vagy
legalabb kozepes szinvonal. Ha szart csinal, akkor is jo munkas. Igy a
manager-ek is ilyenek, nincs motivacio se fent se lent a rangletran,
csak torekves, armanykodas. Tisztesseges programozok lennenek,
legalabb egy alap konyvet elolvasnanak, vagy megneznek, miert rossz,
amit csianlnak, de nem teszik.
--
Tamas
> Azert ennel kicsit masabb a helyzet. Nem is igeny a jo munka, vagy
> legalabb kozepes szinvonal. Ha szart csinal, akkor is jo munkas. Igy a
> manager-ek is ilyenek, nincs motivacio se fent se lent a rangletran,
Nagyon sok motivacio van, csak az meglehetosen enkozpontu illetve
csaladalapitas utan csaladkozpontu, ami joreszt meg mindig
enkozpontusagot jelent (nem veletlen hogy a csillagos eget verdesi az
employee turnover, hogy ok az egyeni vallalkozasok vilagrekorderei
stb)...
> csak torekves, armanykodas.
..., ja, te ezt torekvesnek es armanykodasnak hivod :) Hiaba, mas kultura :)
--
Udv, Sandor
Nemtom mijaza IIT, de HG sem indiai, szal telleg nemcsak indiaikra
jellemzo :)
--
Madarasz Gergely go...@broadband.hu go...@linux.rulez.org
It's practically impossible to look at a penguin and feel angry.
Egy pingvinre gyakorlatilag lehetetlen haragosan nezni.
Vegyél magadnak DAS-t.
És küldd el magánban,h igen vagy nem. :-)
--
Üdvözlettel,
Fejős Tamás
http://fejos.hu
Indian Institute of Technology, elit mernokkepzok amire nagyon buszkek,
csak hat az egymilliardos orszagnak evi kb 2000et kepeznek (aminek csak
kis reszet szamtechen, aztan persze a nem szamtech-esek jo resze is az
IT iparban talal allast mert ott fizetnek jol)...
--
Udv, Sandor
Ebben egyetértek veled.
--
- -
-- Csanyi Andras -- http://sayusi.hu -- Sayusi Ando
-- "Bízzál Istenben és tartsd szárazon a puskaport!".-- Cromwell
> > Szerinted ha összeül egy ilyen kérdés megvitatására pár
> > programtervező, az nem eredményez flamewart? Legfeljebb nem
> > levelezőlistán.
>
> Ezért nem programozóra van szükség, hanem szervezőre :-p
Szerinted a szervezők mennyivel jobbak ebből a szempontból?
--
--- Friczy ---
'Death is not a bug, it's a feature'
k-atti-
BERES Laszlo <sil...@silver.rulez.org> wrote:
> Sorolom: GFS, GFS2, Cluster Suite, Xen. Ezekbe pl. nem kis fejlesztést
> tolt a RH.
ezek melyike hasznos is es jo is? (a xen valamennyire, de mar van kvm, a
tobbi haaaat...)
es azt a 4k stacket sem tudom megbocsatani a redhatnek:)
szerintem a bugfixek ernek valamit, meg hogy kenyeret adnak egy csomo
olyan embernek, aki mindenkeppen kernelt hackelne, csak igy legalisan
teheti munkaidoben. (Persze ha ok nem, akkor adna nekik mas, de azert
nem baj ez igy.)
raas
--
Those who say it cannot be done should not interrupt the person doing it.
-- Chinese proverb
Erről tudhatunk bővebben is?
--
- -
-- Csanyi Andras -- http://sayusi.hu -- Sayusi Ando
-- "Bízzál Istenben és tartsd szárazon a puskaport!".-- Cromwell
Sajnálom, hogy Con Kolivas belefáradt. Mind a három gépemen ck-kernelt
használok és látom a különbséget a gentoo-sources és a ck-kernel közt.
De akkor sajna vissza kell térnem gentoo-sources -ra.
Nem vagyok egy nagy varázsló, szárnyaimat is egyelőre csak php
tekintetében próbálgatom, de tényleg nem értem, hogy miért nem lehet
több választás ugyanazt a célt szolgáló megoldásból.
Olvasva a szál többi levelét kezd formálódni a válasz.
Csányi András <sayus...@gmail.com> wrote:
>> es azt a 4k stacket sem tudom megbocsatani a redhatnek:)
>
> Erről tudhatunk bővebben is?
roviden: az i386-os kernelukben defaultbol be van kapcsolva a 4k stack
nevu opcio, minek kovetkezteben nem lehet elegge halmozni a
szoftverretegeket, meg az (egyebkent unsupported, de csak kikapcsolt)
XFS se megy rendesen. Nem a 4k stack hulyeseg, hanem mindenkinek esz
nelkul bekapcsolni.
raas
--
Those who say it cannot be done should not interrupt the person doing it.
-- Chinese proverb
_______________________________________________________
>> es azt a 4k stacket sem tudom megbocsatani a redhatnek:)
>
> Erről tudhatunk bővebben is?
Nem fogsz, Raas olyan, mint az a madár, amelyik folyton ugyanazt
hajtogatja; mindenre a 4k-s stackkel jön, de konkrétumot sosem mondott
még :D
--
Dr. Szöszi
http://silver.rulez.org
> ezek melyike hasznos is es jo is? (a xen valamennyire, de mar van kvm, a
> tobbi haaaat...)
Hm, nem vagy te egy kicsit beszűkült?
--
Dr. Szöszi
http://silver.rulez.org
hasonlítható a HG -féle "agyatlan maintaineres" reflexeihez? :)
--
- -
-- Csanyi Andras -- http://sayusi.hu -- Sayusi Ando
-- "Bízzál Istenben és tartsd szárazon a puskaport!".-- Cromwell
> Csányi András wrote:
>
> >> es azt a 4k stacket sem tudom megbocsatani a redhatnek:)
> >
> > Erről tudhatunk bővebben is?
>
> Nem fogsz, Raas olyan, mint az a madár, amelyik folyton ugyanazt
> hajtogatja; mindenre a 4k-s stackkel jön, de konkrétumot sosem mondott
> még :D
>
Hát most mondott.
--
Üdvözlettel,
Gábriel Ákos
-=E-Mail :akos.g...@i-logic.hu|Web: http://www.i-logic.hu =-
-=Tel/fax:+3612367353 |Mobil:+36209278894 =-
> Sajnos igen sok indiai programozoval dolgozom, latom mit muveltek
> "programozas" cimen es ilyenkor mindig a kinhalal, es kulonbozo
> kinzasok jutnak eszembe. Minden hibat elkovetnek, amit programozo
> elkovethet. Semmi mentseguk nincs. Komolyen elzavarnam oket, es soha
> tobbet nem engednem szamitogep kozelebe oket, es ha latnad mit
> "programoznak" ossze, szeirntem te is igy tennel.
Legyel egeszen nyugodt, barmelyik felsofoku tanintezmenybol iden
kikerult diplomas magyar is lehet pontosan ugyanilyen. Eselye persze
lehet a fejlodesre, de ebben csak annyi elonye van, hogy jo esetben ert
magyarul. A legnagyobb gaz az indiaiakkal az, hogy nem tudsz veluk
kommunikalni, mert ok nem tudnak angolul, te meg nem tudsz indiaiul.
> On Sun, 24 Jun 2007 22:19:49 +0200
> BERES Laszlo <sil...@silver.rulez.org> wrote:
>
> > Csányi András wrote:
> >
> > >> es azt a 4k stacket sem tudom megbocsatani a redhatnek:)
> > >
> > > Erről tudhatunk bővebben is?
> >
> > Nem fogsz, Raas olyan, mint az a madár, amelyik folyton ugyanazt
> > hajtogatja; mindenre a 4k-s stackkel jön, de konkrétumot sosem mondott
> > még :D
> >
>
> Hát most mondott.
Én is jobban örülnék egy szép, tiszta szituációnak, hibaüzenetekkel.
--
Tomka Gergely, ger...@tomka.hu
> > Hát most mondott.
>
> Én is jobban örülnék egy szép, tiszta szituációnak, hibaüzenetekkel.
>
Kernel témában? Viccelni teccik? :)
--
Üdvözlettel,
Gábriel Ákos
-=E-Mail :akos.g...@i-logic.hu|Web: http://www.i-logic.hu =-
-=Tel/fax:+3612367353 |Mobil:+36209278894 =-
> On Mon, 25 Jun 2007 07:20:19 +0200 (CEST)
> Tomka Gergely <ger...@tomka.hu> wrote:
>
> > > Hát most mondott.
> >
> > Én is jobban örülnék egy szép, tiszta szituációnak, hibaüzenetekkel.
> >
>
> Kernel témában? Viccelni teccik? :)
Nem úgy. Egy olyan jelenet részletesebb leírásának, amikor raas 4k
korlátba ütközik. A csúnya szavakat ki lehet hagyni. Örök bánatom, hogy
nekem sose romlik el a linux kernel*, és nincs elegendő tapasztalatom
ilyen ügyben.
--
Tomka Gergely, ger...@tomka.hu
* Ez szinte arcátlan méretű túlzás, de ide jó lesz :)
> Nem úgy. Egy olyan jelenet részletesebb leírásának, amikor raas 4k
> korlátba ütközik. A csúnya szavakat ki lehet hagyni. Örök bánatom,
> hogy nekem sose romlik el a linux kernel*, és nincs elegendő
> tapasztalatom ilyen ügyben.
Na jo, nekem se szokott. Utoljara akkor senyvedtem vele, amikor a friss
amd64-re kellett forditani, de akkor is jellemzoen kihagytam valamit :)
Annal tobb bajom van viszont pl a cyrus-szal :)
--
Üdvözlettel,
Gábriel Ákos
-=E-Mail :akos.g...@i-logic.hu|Web: http://www.i-logic.hu =-
-=Tel/fax:+3612367353 |Mobil:+36209278894 =-
_______________________________________________________
Tomka Gergely <ger...@tomka.hu> wrote:
> Nem úgy. Egy olyan jelenet részletesebb leírásának, amikor raas 4k
> korlátba ütközik. A csúnya szavakat ki lehet hagyni. Örök bánatom, hogy
> nekem sose romlik el a linux kernel*, és nincs elegendő tapasztalatom
> ilyen ügyben.
egy szoban: xfs (meg csak nem is halmozva a retegeket). Szerencsere
64biten nincs gond ugyebar, es a mai gepek tobbsege meg olyan :P
raas
--
Those who say it cannot be done should not interrupt the person doing it.
-- Chinese proverb
_______________________________________________________
>
> Tomka Gergely <ger...@tomka.hu> wrote:
>
> > Nem úgy. Egy olyan jelenet részletesebb leírásának, amikor raas 4k
> > korlátba ütközik. A csúnya szavakat ki lehet hagyni. Örök bánatom, hogy
> > nekem sose romlik el a linux kernel*, és nincs elegendő tapasztalatom
> > ilyen ügyben.
>
> egy szoban: xfs (meg csak nem is halmozva a retegeket). Szerencsere
> 64biten nincs gond ugyebar, es a mai gepek tobbsege meg olyan :P
Jovan bazmeg, de mi történik?
--
Tomka Gergely, ger...@tomka.hu
BERES Laszlo <sil...@silver.rulez.org> wrote:
> Hm, nem vagy te egy kicsit beszűkült?
Ezt reszletezhetned.
A GFS-hez shared storage kell (legalabb GNBD, de inkabb valami rendes),
a fencing korul voltak kinok, amikor probaltam volna probalni, hogy
mukodik-e. Meg 8TB volt RHEL4-ben a maximalis filesystem meret, ami
kisse szukosnek tunik.
A cluster suite-t hasznalja is valaki egy (lenyegesen egyszerubb)
linux-ha konfig helyett?
raas
--
Those who say it cannot be done should not interrupt the person doing it.
-- Chinese proverb
_______________________________________________________
>> Hm, nem vagy te egy kicsit beszűkült?
>
> Ezt reszletezhetned.
http://www.lelekbenotthon.hu/article.php?sid=10
;)
> A GFS-hez shared storage kell (legalabb GNBD, de inkabb valami rendes),
Ez igaz, de a GFS2-höz már nem.
> a fencing korul voltak kinok, amikor probaltam volna probalni, hogy
Milyen fencing, milyen eszközzel? Ez kicsit általános; nálunk működik
power switch-csel, FC switch-csel, stb.
> mukodik-e. Meg 8TB volt RHEL4-ben a maximalis filesystem meret, ami
> kisse szukosnek tunik.
http://sources.redhat.com/cluster/faq.html#gfs_maxsize
GFS 6.1 (on RHEL 4) supports 16TB when any node in the cluster is
running 32 bit RHEL. If all nodes in the cluster are 64-bit RHEL
(x86-64, ia64) then the theoretical maximum is 8 EB (exabytes). We have
field reports of 45 and 50 TB file systems.
> A cluster suite-t hasznalja is valaki egy (lenyegesen egyszerubb)
> linux-ha konfig helyett?
Igen sokan.
--
Dr. Szöszi
http://silver.rulez.org
Tomka Gergely <ger...@tomka.hu> wrote:
> Jovan bazmeg, de mi történik?
Szerinted mi tortenik, ha kilog egy kernel thread a neki jaro
stackteruletbol? Csunya, gonosz kernel panik.
raas
--
Those who say it cannot be done should not interrupt the person doing it.
-- Chinese proverb
_______________________________________________________
BERES Laszlo <sil...@silver.rulez.org> wrote:
> http://www.lelekbenotthon.hu/article.php?sid=10
"Aki volt már részeg, tudja, hogy az a világ, amit akkor érzékelt,
jelentősen eltér az általa egyébként megszokottól."
:-)
> Ez igaz, de a GFS2-höz már nem.
na, akkor azt felirjuk a todolista vegere.
> Milyen fencing, milyen eszközzel? Ez kicsit általános; nálunk működik
> power switch-csel, FC switch-csel, stb.
qlogic switch, valami storage, not supported, nem megy productionbe.
>> mukodik-e. Meg 8TB volt RHEL4-ben a maximalis filesystem meret, ami
>> kisse szukosnek tunik.
>
> http://sources.redhat.com/cluster/faq.html#gfs_maxsize
>
> GFS 6.1 (on RHEL 4) supports 16TB when any node in the cluster is
> running 32 bit RHEL. If all nodes in the cluster are 64-bit RHEL
hm, akkor ezt updateltek, miota lattam.
> (x86-64, ia64) then the theoretical maximum is 8 EB (exabytes). We have
> field reports of 45 and 50 TB file systems.
45-50TB az mar alakul, de azert..
>> A cluster suite-t hasznalja is valaki egy (lenyegesen egyszerubb)
>> linux-ha konfig helyett?
>
> Igen sokan.
hm. erdekes. Miert?
raas
--
Those who say it cannot be done should not interrupt the person doing it.
-- Chinese proverb
_______________________________________________________
Attol fugg mi van (vagy mi nincs) ott ahova, kilog ;) Mondjuk nagy
valoszinuseggel baj, tenyleg ;)
--
- Gábor
>
> Tomka Gergely <ger...@tomka.hu> wrote:
>
> > Jovan bazmeg, de mi történik?
>
> Szerinted mi tortenik, ha kilog egy kernel thread a neki jaro
> stackteruletbol? Csunya, gonosz kernel panik.
Ennyire nem lehetsz hülye. Mikor történik? Amikor betöltöd a modult?
Amikor mountolod? Valamikor később, véletlenszerűen? Mennyire pánikol?
Hidegindítós-tankos-romantikus, rebootolós-tengerészes? Stb. Hogy kérjem,
hogy leaírj egy ilyen esetet?
--
Tomka Gergely, ger...@tomka.hu
Tomka Gergely <ger...@tomka.hu> wrote:
> Ennyire nem lehetsz hülye. Mikor történik? Amikor betöltöd a modult?
> Amikor mountolod? Valamikor később, véletlenszerűen? Mennyire pánikol?
amikor hasznalod, veletlenszeruen. Nem egy, hanem sok kulonbozo esetben.
> Hidegindítós-tankos-romantikus, rebootolós-tengerészes? Stb. Hogy
> kérjem,
lefagyos, rebootolos. (amugy definicio szerint rebootolos, szerinted
mennyire van egyben egy stack korrupcio utan a kernel? mennyire biznal
ra tovabbi adatot?)
> hogy leaírj egy ilyen esetet?
pl. kezdd el itt olvasni.
http://oss.sgi.com/archives/xfs/2005-07/msg00035.html
meg itt:
http://lkml.org/lkml/2004/7/20/39
es szamold hozza, hogy a RHEL-ben (2.6.9) levo XFS kod osregi, amit
upstreamben javitott bugnak irnak, az itt nincs javitva.
(n.b. az XFS nem tamogatott RHEL-ben, de az ext3 meg bizonyos celokra
erosen szuboptimalis, peldaul probalj meg nagy file-okat torolni)
Majd asok elo valami dumpot, ha megvan meg. Addig talalhatsz magadnak
levelet dogivel, ahol altalaban a jonehany reteg (pl. driver+md+lvm+nfs)
egyutt mar tul sok a 4k-nak.
raas
--
Those who say it cannot be done should not interrupt the person doing it.
-- Chinese proverb
_______________________________________________________
>
> Tomka Gergely <ger...@tomka.hu> wrote:
>
> > Ennyire nem lehetsz hülye. Mikor történik? Amikor betöltöd a modult?
> > Amikor mountolod? Valamikor később, véletlenszerűen? Mennyire pánikol?
>
> amikor hasznalod, veletlenszeruen. Nem egy, hanem sok kulonbozo esetben.
>
> > Hidegindítós-tankos-romantikus, rebootolós-tengerészes? Stb. Hogy
> > kérjem,
>
> lefagyos, rebootolos. (amugy definicio szerint rebootolos, szerinted
> mennyire van egyben egy stack korrupcio utan a kernel? mennyire biznal
> ra tovabbi adatot?)
Nyilván semennyire, ezért nincsen boldoganélmígmegnemhalós,beszélőállatos
opció :)
köszi.
> Majd asok elo valami dumpot, ha megvan meg. Addig talalhatsz magadnak
> levelet dogivel, ahol altalaban a jonehany reteg (pl. driver+md+lvm+nfs)
> egyutt mar tul sok a 4k-nak.
Ask them if they support NFS V4 on top of ext3 on top of multipathing on
top
of network block device with a 4K stack under low memory conditions.....
:) köszönöm. És bocs a kifakadásért, nem sokkal egy tkomos tleefon után
jött :)
--
Tomka Gergely, ger...@tomka.hu
na kedves TG, tessek backtrace. i386, RHEL4 (vagyis ujraforditott xfs-es
kernel), kozvetlenul a driver tetejen lokalis xfs, sok thread, eros I/O
load.
(64biten nincs ilyen problemank, ugyhogy egyszeruen ahol xfs, az 64bites
es kesz :P )
XFS mounting filesystem sdb1
mount: page allocation failure. order:4, mode:0xd0
[<c014bc2f>] __alloc_pages+0x2e1/0x2f7
[<c014bc5d>] __get_free_pages+0x18/0x25
[<c014f0fa>] kmem_getpages+0x15/0x94
[<c014fdb0>] cache_grow+0x107/0x233
[<c01500d3>] cache_alloc_refill+0x1f7/0x227
[<c0150609>] __kmalloc+0x6b/0x7d
[<f8c3256c>] kmem_alloc+0x50/0x96 [xfs]
[<f8c34a1e>] pagebuf_get_no_daddr+0x41/0x99 [xfs]
[<f8c1e9a6>] xlog_get_bp+0x5e/0x61 [xfs]
[<f8c1ef90>] xlog_find_verify_log_record+0x35/0x243 [xfs]
[<f8c1fb20>] xlog_find_zeroed+0x1f7/0x235 [xfs]
[<f8c1f1c4>] xlog_find_head+0x26/0x3d2 [xfs]
[<c03186f3>] schedule+0x43f/0x552
[<f8c33f69>] _pagebuf_initialize+0x13c/0x157 [xfs]
[<f8c1f586>] xlog_find_tail+0x16/0x3b9 [xfs]
[<f8c34858>] pagebuf_get_empty+0x2a/0x33 [xfs]
[<f8c22fe4>] xlog_recover+0x16/0x92 [xfs]
[<f8c19e33>] xfs_log_mount+0x78/0xb8 [xfs]
[<f8c2474f>] xfs_mountfs+0x91b/0xb8f [xfs]
[<f8c23828>] xfs_xlatesb+0x37/0x23c [xfs]
[<f8c35507>] xfs_setsize_buftarg+0x2a/0x59 [xfs]
[<f8c34a9c>] pagebuf_rele+0x22/0x1c4 [xfs]
[<f8c1659b>] xfs_ioinit+0x1e/0x21 [xfs]
[<f8c2ae3f>] xfs_mount+0x2a2/0x313 [xfs]
[<f8c3b352>] vfs_mount+0x1a/0x1d [xfs]
[<f8c3b220>] linvfs_fill_super+0x76/0x17a [xfs]
[<c01ebc95>] snprintf+0x17/0x1a
[<c01a98ae>] disk_name+0x56/0x60
[<c0170568>] get_sb_bdev+0xe0/0x11c
[<c014bd00>] __free_pages+0x36/0x49
[<c014bd3d>] free_pages+0x2a/0x2b
[<c01ce943>] selinux_sb_copy_data+0x158/0x164
[<f8c3b332>] linvfs_get_sb+0xe/0x14 [xfs]
[<f8c3b1aa>] linvfs_fill_super+0x0/0x17a [xfs]
[<c0170732>] do_kern_mount+0x8a/0x144
[<c018a87b>] do_new_mount+0x4e/0x6f
[<c018b2eb>] do_mount+0x178/0x190
[<c018b7a0>] sys_mount+0x10d/0x1df
[<c031a85f>] syscall_call+0x7/0xb
raas
--
Those who say it cannot be done should not interrupt the person doing it.
-- Chinese proverb
_______________________________________________________
> na kedves TG, tessek backtrace. i386, RHEL4 (vagyis ujraforditott xfs-es
Innentől kezdve kár vitatkozni.
--
Dr. Szöszi
http://silver.rulez.org
> Andras HORVATH wrote:
>
> > na kedves TG, tessek backtrace. i386, RHEL4 (vagyis ujraforditott xfs-es
>
> Innentől kezdve kár vitatkozni.
Mert egyetértünk?
--
Tomka Gergely, ger...@tomka.hu
>> Innentől kezdve kár vitatkozni.
>
> Mert egyetértünk?
Nem. Recompiled RHEL kernel, ki tudja, mi van benne.
--
Dr. Szöszi
http://silver.rulez.org
> Tomka Gergely wrote:
>
> >> Innentől kezdve kár vitatkozni.
> >
> > Mert egyetértünk?
>
> Nem. Recompiled RHEL kernel, ki tudja, mi van benne.
Ne legyél agymosott lécci... Hadd éljen bennem a remény, hogy van
kb. féligelfogult szakember oprendszerforgalmazó/supportáló cégnél...
--
Üdvözlettel,
Gábriel Ákos
-=E-Mail :akos.g...@i-logic.hu|Web: http://www.i-logic.hu =-
-=Tel/fax:+3612367353 |Mobil:+36209278894 =-
Miül nem tudsz te? :)
--
Udv, Sandor
> Gábriel Ákos wrote:
> > kommunikalni, mert ok nem tudnak angolul, te meg nem tudsz indiaiul.
>
> Miül nem tudsz te? :)
>
indiaiul, természetesen :)
--
Üdvözlettel,
Gábriel Ákos
-=E-Mail :akos.g...@i-logic.hu|Web: http://www.i-logic.hu =-
-=Tel/fax:+3612367353 |Mobil:+36209278894 =-
Ugye csak szimulalsz itt nekunk? :)
--
Udv, Sandor
> Gábriel Ákos wrote:
> > kommunikalni, mert ok nem tudnak angolul, te meg nem tudsz indiaiul.
> Miül nem tudsz te? :)
Ezéül:
Assamese, Bengali, Bodo, Dogri, Gujarati, Kannada, Kashmiri, Konkani,
Maithili, Malayalam, Manipuri, Marathi, Nepali, Oriya, Punjabi,
Sanskrit, Santhali, Sindhi, Tamil, Telugu, Urdu, sötöbö..
--
Üdvözlettel: Smith & Wesson:
Cemasko Viktor. the original point-and-click interface.
Ja vagyugy ;-)
--
Udv, Sandor
> Ne legyél agymosott lécci... Hadd éljen bennem a remény, hogy van
> kb. féligelfogult szakember oprendszerforgalmazó/supportáló cégnél...
Na jó, de csak a te kedvedért :)
Biztos vagyok abban, hogy Raas tud megfelelő kernelt forgatni magának.
Abban viszont nem vagyok biztos, hogy a RHEL kernele és Raas megfelelő
párosítás :)
--
Dr. Szöszi
http://silver.rulez.org
BERES Laszlo <sil...@silver.rulez.org> wrote:
> Abban viszont nem vagyok biztos, hogy a RHEL kernele és Raas megfelelő
> párosítás :)
a binaris RHEL kompatibilitas policy, amit nem en talaltam ki, ellenben
hosszu tortenet. Amugy igazad van ;-)
raas
--
Those who say it cannot be done should not interrupt the person doing it.
-- Chinese proverb
_______________________________________________________
Ez nekem igen durva... Ismet egy ok, hogy soha ne akarjak
redhatot hasznalni.
--
Udvozlettel
Zsiga
> On Mon, Jun 25, 2007 at 05:49:09PM +0200, BERES Laszlo wrote:
> > Tomka Gergely wrote:
> >
> > >> Innentől kezdve kár vitatkozni.
> > >
> > > Mert egyetértünk?
> >
> > Nem. Recompiled RHEL kernel, ki tudja, mi van benne.
>
> Ez nekem igen durva... Ismet egy ok, hogy soha ne akarjak
> redhatot hasznalni.
Soha se mondd, hogy sohase :)
--
Tomka Gergely, ger...@tomka.hu
Erdekes, multkor meg tiltakoztal, amikor azt emlegettem, hogy az
enterpriselinux support addig tart, amig a default installt hasznalod,
ha egy dir-rel arebb mountolsz valamit, akkor beintenek. Total windows,
csak azt nem ertem, miert nem livecd formajaban adjatok ki, kell moge
egy storage, amin az adatok vannak, oszthali. Havonta kuldtok egy uj
cdt, igy megvan az upgrade is.
--
Gabor HALASZ <hala...@freemail.hu>
>> Nem. Recompiled RHEL kernel, ki tudja, mi van benne.
>
> Ez nekem igen durva... Ismet egy ok, hogy soha ne akarjak
> redhatot hasznalni.
Csibike, mi az úristent nem lehet ezen érteni? Van egy disztrib, kapsz
hozzá egy kernelt, azt használod. Ha hozzányúlsz, az már nem RHEL, senki
nem garantálja, hogy működni fog. Ennyi. Nem kell RHEL-t használni, ha
mégis megteszed, akkor tudnod kell, milyen megkötéseid vannak.
Esküszöm, a gyerekeim előbb megértenek dolgokat...
--
Dr. Szöszi
http://silver.rulez.org
--
Gabor HALASZ <hala...@freemail.hu>
> BERES Laszlo wrote:
> > Kosa Attila wrote:
> >
> >>> Nem. Recompiled RHEL kernel, ki tudja, mi van benne.
> >> Ez nekem igen durva... Ismet egy ok, hogy soha ne akarjak
> >> redhatot hasznalni.
> >
> > Csibike, mi az úristent nem lehet ezen érteni? Van egy disztrib, kapsz
> > hozzá egy kernelt, azt használod. Ha hozzányúlsz, az már nem RHEL, senki
> > nem garantálja, hogy működni fog. Ennyi. Nem kell RHEL-t használni, ha
> > mégis megteszed, akkor tudnod kell, milyen megkötéseid vannak.
>
> Erdekes, multkor meg tiltakoztal, amikor azt emlegettem, hogy az
> enterpriselinux support addig tart, amig a default installt hasznalod,
> ha egy dir-rel arebb mountolsz valamit, akkor beintenek. Total windows,
Mert ez már nem igaz, vaze.
--
Tomka Gergely, ger...@tomka.hu
Halaszg megelozott (szerencsere), en sokkal durvabb lettem
volna...
--
Udvozlettel
Zsiga
> Erdekes, multkor meg tiltakoztal, amikor azt emlegettem, hogy az
> enterpriselinux support addig tart, amig a default installt hasznalod,
> ha egy dir-rel arebb mountolsz valamit, akkor beintenek. Total windows,
Illendő lenne észrevenni a kernel basztatása és a telepítés/konfigurálás
testreszabása közötti különbséget.
--
Dr. Szöszi
http://silver.rulez.org
> Halaszg megelozott (szerencsere), en sokkal durvabb lettem
> volna...
Lassan én is durvább leszek. Sírtok, mint a fürdőskva, aztán fáj, ha
valakinek valami működik. Mit nem lehet megérteni azon, hogy a kernelhez
_nem_ lehet_hozzányúlni_?
--
Dr. Szöszi
http://silver.rulez.org
> Ilyenkor derul ki, hogy semmi kulonbseg a redhat es az m$ (es a tobbi
> hasonlo ceg) kozott.
Figyelek.
--
Dr. Szöszi
http://silver.rulez.org