Mi várható a Linux 2.6.13-ban? Reiser4, FUSE...

kedvenc reszem: "CONFIG_HZ for x86 and ia64: changes default HZ to 250, make HZ Kconfigurable. Will merge (will switch default to 1000 Hz later if that seems necessary)"

ne koptassuk mar a stabil szot feleslegesen

jah, en is jot rohogtem. milyen stabil cucc az, amibe ennyi uj feature-t raknak? jezusom, nem akarom tudni mire mondanak hogy unstable....

Linus, nyisd ki a 2.7-es fat! :)

Én inkább a Reiser4-től ijedtem meg. Persze, nem kötelező ezt használni, de én nem tartom stabilnak.

A Reiser 3.6-tal nagyon meg vagyok elégedve: stabil, biztonságos, gyors. Azt hiszem, nem csak én gondolom így, másoktól is sok jót olvastam róla, és sok disztribúció (pl. SuSe) is ezt használja defaultként.

Annak idején nagyon vártam a Reiser4-et, mert óriási durranásnak harangozták be. Sok területen tényleg gyorsabb, de nagyon fogja a CPU-t, és a stabilitása kriminális. Nekem áramszünet és reboot nélkül is okozott olyan bibit, amit két órás fsck-val is alig tudott rendberakni. És szerintem ezzel sem voltam egyedül.

Ehhez persze hozzájárulhatott az is, hogy össze-vissza kellett patchelni a kernelt (bár a Con Kolivas-féle elég jónak tűnt.) Talán, ha bekerül a mainstream kernelbe, könnyebb lesz tesztelni és bugreportolni.

Addig is marad a Reiser 3.6!

Eddig 2.x.4, 2.x.5 körül volt érdemes kernelt váltani, addigra lett stabil. Most 2.6.x.4, 2.6.x.5?

Ezt a sok felesleges szocseplest. Egyelore(hala a magasagosnak) nem ti dontitek el mi a stabil. Ha ezt kiadjak stabilnak akkor ki lesz adva. Aki sir az meg ne hasznalja.

Nocsak lesz OCFS2 es Xen is :)

Konyorgom, mondja el mar valamelyikotok hogy pl mitol lesz szerintetek unstable a 2.6.13, ha belerakjak a reiser4-et.

"Szeretem" hogy mekkora divat lett fikazni a kernel fejlesztoket, hogy ennyien meg is teszik, es a legszebb hogy altalaban mindezt kulonos kompetenciaval.

>Én inkább a Reiser4-től ijedtem meg. Persze, nem kötelező ezt használni, de én nem tartom stabilnak.

Akkor ne hasznald es kesz. Rohadtul nem ertem mit parazol.

> Annak idején nagyon vártam a Reiser4-et, mert óriási durranásnak harangozták be. Sok területen tényleg gyorsabb, de nagyon fogja a CPU-t,

Az, hogy fogja a cpu-t, pont a gyorsasag kovetkezmenye...

(rovidebb ido alatt vegez, es gyk disk-io idot cpu idore "trade"-el.)

> és a stabilitása kriminális. Nekem áramszünet és reboot nélkül is okozott olyan bibit, amit két órás fsck-val is alig tudott rendberakni.

Az fsck hossza valoszinuleg fuggetlen a hibasodas merteketol, sokkal inkabb fugg a filerendszer meretetol, illetve kihasznaltsagatol.

Egyebkent pedig meg volt mondva hogy ne hasznald eles adaton, nem ertem mit csodalkozol, illetve miert fikazod.

> És szerintem ezzel sem voltam egyedül.

"Szerintem". A jol megalapozott ervek.

> Ehhez persze hozzájárulhatott az is, hogy össze-vissza kellett patchelni a kernelt (bár a Con Kolivas-féle elég jónak tűnt.) Talán, ha bekerül a mainstream kernelbe, könnyebb lesz tesztelni és bugreportolni.

Talan pont ezert akarjak vegre belerakni...

:))))

Amig nem rak elem egy IRQL_NOT_LESS_OR_EQUAL-t, addig en aszondom hogy desktopra eleg stabil. Szerveren ugyis marad a 2.4.

Az uj feature-oknek meg orulok. A 400 gigas LVM kotetemet sem akkor fogom atkonvertalni Reiser4-re amikor valaki beirja egy file-ba hogy "stable"... Hanem majd akkor amikor kellokeppen berugtam, es nincs egyeb programom a hetvegere.

Yeah, vegre inotify... mar csak a software suspend 2 kene, es csicsa-ragya-fa..a lenne az egesz :)

egyetértek Pozsyval. Attól, mert a kód bekerül és TE nem használod (TE = bármelyik rendszergazda) a kerneled nem lesz instabilabb. Ráadásul a Reiser 3.6 is a 2.4.18 után lett stabil, ahogy fel is hívták rá a figyelmet. De kellett hozzá, hogy benne legyen a kernelben és sokan teszteljék akár éles - sic! - adatokon is. Életszerű környezetnek hívják. De az biztos, hogy SuSE/Novell, RH is fogja gyűrni rendesen, bár RH eléggé ext3-ra van rágyógyulva, ahogyan én is, de a stabillá vált Reiser4-et én is kipróbálnám és használnám. Minden oldalról vannak horror sztorik: ext3 szét.... a filrendszeremet, resiserrel soha nem történt meg és viszont típusú levelek. Közben pedig lehet, hogy rossz ram miatt került korrupt info a filerendszerre - mielőtt flamet kapok nézzék meg az írók a reg ECC-s ram mire is jó - pont olyan összeállítással és kernel konfiggal történt ez stb. Bármi lehetséges, met az eszközök és a futó rendszerek 90%-ban egyezhetnek, de a maradék 10%, (vagy akár 5%) olyan változásokat eredményezhet, ami megjósolhatatlan.

In article <42.46181@c.hup.hu>, Ago wrote:
> egyetértek Pozsyval. Attól, mert a kód bekerül és TE nem használod (TE > bármelyik rendszergazda) a kerneled nem lesz instabilabb.

Hujuj nagyon megy itt az eszosztas szokas szerint.

A kurvanagy reiser4 kod importja termeszetesen total fuggetlen lesz am a
kernel tobbi reszetol, meg akkor is ha regen pont ennek ellenkezojerol volt
cikk raadasul pont itt a blikk.hu-n, hapersze fakitsunk csak.

Reiser3 is akkora nagy fasza csoda h legutobb mikor a szar samsung vinyom
tulmelegedett, a reiser driver osszekorruptolta a masik vinyon levo fs
(chroot) driveret is -> reboot.

A linux (yea, yea, halleluiah) ismetelten megmutathatta mennyire fuggetlenek
egyes reszei a masiktol (semennyire).

--
Bérczi Gábor
/Gabu/

Egyetertek! Sot ahogy egyszer asszem' Linus is mondta: a kernelnek nincs koze ahhoz amit amikor o kiad: a disztributor feladata hogy olyan kernel biztositson neked, ami megfeleloen mukodik az adott disztribucioban, ideertve ugye az esetleges patch-eket, meghat nyilvan azt is, hogy tesztelt stabil cucc legyen. Linus ehhez az "alapanyagot" adja.

Meg persze tenyleg nem tul celravezeto fejbvesztve upgrade-elni mindent, legyen szo barmely software uj verziojarol. Soha nem ertettem aki csak erre gyur, aztan sir hogy nem stabil a rendszere, valami nem mukodik stb :)

Nem ertelek. Ne hasznald akkor a reiser4-et ilyen egyszeru. Szerintem ez a fejlesztesi forma SOKKAL de SOKKAL jobb mint a regi "parhuzamosan futtasunk stable es unstable agat" aztan azert stabilizalodott olyan lassan mindig a 2.2.x is pl mert mire olyan allapotba hoztak ...

megegyezhetunk abban, hogy kettonk kozul Te ertesz jobban a kernelhez, de nekem akkor is rosszabbak maradnak a tapasztalataim a 2.6-tal. pl rackba tett hdd-t nem ismerte fel meg regebben (FrugalWare telepitessel szivtam igy), amikor probe-olta a kontrollert, uresnek latta. UA volt egy akkori Debian netinstallal is, mig a 2.4 csont nelkul elindult rajta, aztan nehany ide hiba utan kikapcsolta a DMA-t. _en_ jobban orulnek, ha az uj stuffokat a 2.7-be tennek, ezt meg fixelnek.

Gabucino. Mi a f.sznak kell allandoan belemenned ebbe a szemelyeskedo, kiokosito hangnembe?

Nem zavar ha segg-lyuuuknak neznek miatta?

Kar..

Mar ha elhagynad a szemelyeket meltato reszeket sokkal szakmaibb lenne ez a tetves hozzaszollas.

In article <42.46186@c.hup.hu>, Willy wrote:
> Gabucino.

^- ennyit arrol hogy ki szemelyeskedik.

--
Bérczi Gábor
/Gabu/

hahahah

attol hogy a reiser4 egy hugy

finoman szolva

olyan foku intelligenciat feltetlezel, hogy vki megertse, hogy a stabilitas nem azt jelenti, hogy tuxracerben lecsuszol a hegyoldalon es kozben nem fagy csontta a geped, hanem hogy nincsenek major _valtozasok_ (tehat nem bovulesrol beszeltem), illetve hogy vannak userek, akik nem bootsplash cserelgetesre es -O99 matyizasra hasznaljak a tesc0 gazdasagos cerkaikon - a 2.4.x unmaintained volta miatt - ezt a fat

szerintem gondold at kicsit amit leirtal. Aztan nezd meg, hogy egy nagy patchet hany darabba szoktak vagni. Nem kell valaszolnod, mert beloled hianyzik az a fajta ero, hogy beismerd, ha tevedsz, ahogy latom.

Ettol?

- I'm not sure it's had enough review.

- check that they've looked at it sufficiently closely.

- Needs some convincing benchmark numbers to back it up

- I have a comment "The below break x440". Maybe it got fixed.

- Heaven knows. Will merge.

- here are still questions around the implementation.

- There are still concerns about the userspace API and internal implementation details

- Issues around add-page-becoming-writable-notification.patch need to be resolved.

- Needs review from NFS developers and considerably more testing.

- We're still deadlocked over some permission-checking hacks in there

Én inkább a Reiser4-től ijedtem meg. Persze, nem kötelező ezt használni, de én nem tartom stabilnak.

A Reiser 3.6-tal nagyon meg vagyok elégedve: stabil, biztonságos, gyors. Azt hiszem, nem csak én gondolom így, másoktól is sok jót olvastam róla, és sok disztribúció (pl. SuSe) is ezt használja defaultként.

Hat, nekem reiser3-mal tobb gepen tobb fs megborult mar. ext3-mal is volt, azt hiszem 1 eset.

Igen rosszul esett mind, pedig volt valamennyi mentes, de nem szeretnem ujra atelni. Szerencsere az elmult kb. 1 evben egyik sem doglott meg.

Hat, majd megnezem a 4-es reisert, aztan majd meglatom, hasznalom-e, vagy varok vele.

Ahhoz kepest mondjuk, hogy az egesz 2.6-os sorozat mennyire gaz volt, most ez mar nem sokat szamit :-)

Bar most mar egesz jo, mar csak nehany kisebb dolog nem mukodik.

G

Ha elolvastad, latod, hogy itt azokrol van szo, amik nem automatikusan kerulnek be a kernelbe.

Sok altalad irt sor azt jelenti, hogy az adott funkcio nem kerul be a kernelbe.

Tehat az ismert hibaktol/problemaktol nem lesz instabil, mert nem kerulnek a stabil agba.

inotify

There are still concerns about the userspace API and internal

implementation details. More slogging needed.

Szoval inotify nem lesz.

LOL: -O99 matyizásra

Igen ezeknek a bugoknak tenyleg csak a fele fog bekerulni :)

Egyaltalan nem ertem miert jonnek szoba ezek a dolgok mint lehetseges 2.6.13-ba bekerulo funkciok. Remek pelda a listaban ez: swsusp-on-SMP (most akkor eddig ez hogyan is ment?) Vagy pl 2.6.12-ben bugos a conntrack bridge interfacekon. Vagy az egeszseges, hogy az smp-n (es talan preempten is) honapok ota bugos netfilter owner matchet ugy akarjak megoldani, hogy bazi nagy ifdefet beletolnak, hogy smp-n elkuldjon a rakba? Es elegge sokaig lehetne folytatni a sort. Ezek a bugok mar most benne vannak

Tenyleg sokan szidjak a 2.6-ot, nem hinnem, hogy mindenki divatbol. Lehet, hogy egy atlag user keves problemaba akad bele, de mindenfele specialis kornyezetben ("a linux mindenre jo") lehet nagyokat szivni vele. Amikor jo sok gep van a kezed alatt, akkor nem feltetlenul szeretnel minden gepen massal szivni, es keresgelni a hiba okat. Egyszeru paraszt modjan csak azt szeretned, hogy ami benne van az mukodjon.

> En is szeretnem, hogy ingyen legyen autom, lakasom, vilagitson a lampam, stb.

Itt egyaltalan nem a penzrol van szo, ha valakit ezek a hibak nagyon zavarnak, es sok idejet veszik el, akkor az ceges kornyezet. Ott van penz is, de ez nem fog segiteni sokat a dolgon.

1. Megteszem 1X, 2X, aztan 3X mar nem mert nem ertek annyira hozza. Hosszu tavon nem ez a megoldas.

2. 1 kezemen meg tudom szamolni hany olyan emberrel talalkoztam, aki komolyabban piszkalgatta a kernelforrast. Fizetos disztrok sem nyujtanak erre megoldast, konkret pelda volt erre is, amikor azert kellett mas disztro-t valasztani, mert egy csunya bug miatt keptelenseg volt normalis mukodesre birni a sambat. Persze ki lehetett volna hekkelni, de azert fizetek, hogy a disztrogyarto megtegye legalabb bugreport utan (nem tettek)

3. Remek otlet, de megis mit? :)

>Mi a problem?

Azabaaaj, hogy ez nagyon nem a beharangozott enterspajz. A megnagyobb problem, hogy lehetne belathato idon belul az, de megis rossz iranyba haladnak (szerintem). Tudom hogy nincs tokeletes kod a vilagon, de ez nem vigasztal iszonyatos hosszu szopas utan, mikor rajossz, hogy nem Te vagy a balf@sz, hanem beleakadtal egy csunya bugba.

:DDDDD

Ez Freudi elszólás volt! ;P

Ehh várom már a Dragonfly BSD 2.0-t. Akkor viszlát linux , persze nem enterprise.... :))

ÜDV

Godot

Ezt majd velunk is megosztod? Bar jol hangzik, de nem teljesen ertem, hogy lenyegeben valamifele SAN szeru megoldasrol lenne szo?

> Ennekem meg megy az Oracle, a DB2...

Kirajsag. En is sokfele celra hasznalom amivel fizetos softwaret valtok ki, de csak akkor, ha valoban jobb is mint a fizetos termek. Szerintem nem attol lesz jobb, hogy beraknak tonna bugos cuccot, marketingelnek vele, majd 5 verzioval es 15 patchel kesobb mar valoban hasznalhato lesz. Attol sem lesz enterspajzabb, hogy kprobe-ot raknak csak azert, hogy valami dtrace-el szemben fel(nem)mutathato dologgal menozzenek. (hany ember hasznalja vajon kprobe-ot 50? vagy akar meg az is lehet, hogy 200?)

Egyebkent meg nem a linuxal van bajom, csak azzal amit a 2.6-al muvelnek.

Ja, es a 4. lehetoseg: maradok 2.4-nel amig meg nem nyitjak a 2.7-es agat :)

Hat neha befigyel vanilla kernel par dolog miatt. Debian alatt pedig szinte mindig vanillat hasznaltam. Valoban igazad van, a vendorok odafigyelnek, es nem rakjak be. (persze azert elofordul) Innentol kezdve AKPM elmelete a gyorsan fejlodo kernelrol meg is bukott, viszont jol megdolgoztatja a disztrokeszitoket, akiknek szepen lehet kipeccselni a cuccokat :)