Linus szerint a crashdump szar (a Solaris-szal együtt)

Kernel

Az LKML-en egy debug-olással kapcsolatos beszélgetésben felvetődött, hogy a Linux kernel fejlesztőinek példát kellene venniük a Solaris-ról, ahol a kernel összeomlása esetén az memóriadump-ot készít a swap területre, tesz rá egy flag-et, majd a következő boot során a memóriatérképet bemásolja a swap-ről a /var/adm/crashdump könyvtárba, ott megőrizve a későbbi hibakeresésekhez. Természetesen ahhoz, hogy ez működjön, a swap-nek nagyobbnak kell lennie, mint a core-nak (azon memóriaterületnek, amelyet a diszkre kell írni). Bár igaz, hogy ez csak Sun gépeken egyszerű, mert azokon ezt az OBP-n (OpenBoot PROM) keresztül el lehet végezni, míg Solaris-t futtató !Sun gépek esetén ez körülményesebb, mert probléma esetén olyan kernelre van szükség, amely még legalább annyira "él", hogy a dump-ot ki tudja írni.

A felvetésre Linus a tőle nem szokatlan nyersességgel válaszolt. Szerinte nem kell példát venni a Solaris-tól ebben az esetben, mert a Solaris szar. Szerinte a Solaris fejlesztők az alapján hoznak döntéseket, hogy feltételezik, hogy "mi kontrolláljuk a hardvert". Linus szerint több szempontból sem jó megközelítés összeomlás esetén a lemezre írni. Linus szerint a legtöbb összeomlás esetén a rendszer olyan "törékeny" állapotban van, hogy a leges-legutolsó dolog lehetne az, amit a fejlesztő ilyenkor tenni szeretne az, hogy ír a lemezre.

Linus szerint egy "kontrollált környezetben" a memória image lemezre írása helyes eljárás lehet. Viszont ilyen "kontrollált környezetben" sose kaphat a felhasználó olyan rugalmas felhasználást, mint amit a Linux esetén kap. Linus szerint a Linux pont azért terjedt el, és "lopott el" egy csomó részesedést a kereskedelmi UNIX-ok piacán, mert a kereskedelmi UNIX-okkal szemben a rendszerek széles skáláján (nem kontrollált környezetben) fut. Linus szerint a tradícionális UNIX-ok hardver / felügyeleti modellje (gyanítom, hogy itt arra gondol, hogy ezek a UNIX-ok majdnem célhardvereken futnak, és nincs olyan széles lehetőség a futtatásra, mint a Linux esetén, ami gyakorlatilag mindenen fut, amiben processzor van) nem működik. Az emberek nagyobb flexibitást akarnak, mind hardver, mind használat területen, és ha flexibitást szeretnénk, akkor a "dump-oljunk mindent a diszkre" megközelítés egyszerűen nem működik.

Szerinte a disk dump-ok olyan környezetekben lehetnek opciók, mint például a Wall Street (ahol a korábban említett (szinte cél)hardvereken futó kereskedelmi UNIX-ok nagy számban megtalálhatók. Linus szerint, ezt a megközelítést a Linux esetén el kell felejteni, mert teljesen hibás. Linus szerint nekik rövid és kellemes bugreport-okra van szükségük. Elég, ha a bugot bejelentő bemásolja a képernyő tartalmát, vagy készít egy digitális fotót.

Alan Cox egyetértett Linus-szal. Szerinte további probléma a crashdump-okkal, hogy azok érzékeny információkat tartalmazhatnak - 3rd party copyright-ok, személyes infókat, stb. Alan szerint a crashdump akkor hasznos, ha a bug bejelentője egyenesen a gyártónak jelent bugot szigorú szerződések mellett, amelyek szabályozzák az adatkezelést, vagy magának crash-elteti el a box-át, és elemzi a dump-ot. Ez Linux esetén - ahol a legtöbb esetben a bugok bejelentése nem ily módon történik, használhatatlan.

Bővebben a KernelTrap összefoglalójában.

( Zahy v | 2007. 05. 26., szo – 10:22 )

Megközelítés legalábbis érdekes, végkövetkeztetés katasztofális :-(

Igen, elsőre én is ezt gondoltam. BSD-itis. De van valami abban, amit mond.

Az egy releváns különbség, hogy ott, ahol a Solaris (vagy a BSDk) elpánikolnak, a Linux csak egy oops-ot dob. Tehát a legtöbb egyszerű programozási hiba élő rendszerben elemezhető (elemezendő) Linuxon; ha pánik van, az már tényleg gáz, és akkor nem kéne diszkre írogatni. A Linux fejlesztési modelljét figyelembe véve ezek logikus megfontolások.

Azon persze lehet vitatkozni, hogy a "fail early, fail loud" mennyire követendő elv, ill. hogy a hiba idejében készült snapshotot könnyebb-e debuggolni vagy a tovább is élő rendszert. De ez más kérdés, ilyen mi lenne ha irányba szerintem ne kalandozzunk el.

És az se hülyeség, hogy a dump szeku okokból nem igazán alkalmas hibariportolásra, developerek meg bekapcsolhatják saját használatra a kdumpot.

( goodbyte v | 2007. 05. 26., szo – 10:24 )

"Linus szerint a legtöbb összeomlás esetén a rendszer olyan "törékeny" állapotban van, hogy a leges-legutolsó dolog lehetne az, amit a fejlesztő ilyenkor tenni szeretne az, hogy ír a lemezre."

Nos, szvsz ezzel nem nagyon lehet vitatkozni, nemde?

Azok, akik ezt használják nyilván vitatkoznának vele.

Elképzelem például Mezei Pistike alkalmi rendszergazdát, az olcsóhosting bt géptermében elhelyezett asztali szerverpécéjével. Ami valami reiserfs bug miatt lerohad. Pistike bugreportolna, de van néhány problémája:
- a gép lerohadt, tehát nem fér hozzá
- az olcsóhosting bt csak reset gomb nyomkodására van felkészülve, képernyőről való OCR feladatok ellátására nem
- digitális fényképezővel sem szokták szembesíteni a monitorokat, hiszen nem parkolóőrök

Pistike tehát kér resetgombnyomást, kernelt upgrade-el és reménykedik, hogy az az ismeretlen hiba, ami mindig akkor üt be, amikor ő nem szívesen foglalkozna a géppel abban már elmúlt.

Ha ezt összeveted a crashdumpos megoldással:
- gép lerohad, crashdump készül, gép automatikusan újraindul
- Pistike észre sem veszi a dolgot, mert az ügyfelei annyira nem nagyvállalatiak, hogy egy ötperces leállásért szóljanak
- ha mégis észreveszi, belekukkant a crashdumpba, küld egy backtrace-t a fejlesztőknek (vagy áttér reiserfs-ről a hiperstabil ext3-ra) és mindenki örül

Értem. De hogy ez hogy jön ide, azt már nem. Arról beszéltem, hogy a lúzer rendszergazda hogy fogja soros porton debugolni a kernelét mikor az lerohad. Ha végigolvasod ezt a szálat azt is láthatod, hogy a rendszergazda nem az ISP-nél dolgozik, tehát adott esetben nagy az esély arra, hogy nincs azonos épületben, vagy akár városban vele.

"Mezei Pistike alkalmi rendszergazdát"

Elképzeltem Mezei Pistike rendszergazdát, aki olcsóhostingnál elhelyezett asztali szerverpct üzemeltet, és minden vágya (és a skill-je is megvan hozzá :)), hogy crash esetén legyen egy dumpja, amit majd jól megelemez. Ilyenkor a Mezei Pistikék (elnézést Mezei Péter nevű olvasóinktól) felmennek a hostingba', megvakarják a fejüket, majd vállat vonva újrahúzzák a gépüket. "Újra köllött húznyi, mer' megfagyott" :)))

PS: Kípernyőképet lehet lecsalni iLO vagy azzal egyenértékű motyóról is :)

(Aprópó: voltam már olyan hivatalos Windows tanfolyamon, ahol a nagytekintélyű előadó maga mondta, hogy a Windows hasonszőrű funkcióját ki _kell_ kapcsolni, mert ha a rendszer megdöglik, akkor "abból a dump-ból, még (mezei)ember nem olvasott ki semmit (ő legalábbis még nem látott olyan rendszergazdát, aki nekiállt volna elemezni), annak meg marha kicsi az esélye, hogy az MS szóba áll vele, ha bekopog egy reklámszatyornyi dump-pal náluk, így csak a helyet foglalja". Nyilván nem nagyvállalati környezetre gondolt az úr.)

--
trey @ gépház

Én azt mondom, hogy a lehetőség nem hülyeség, a cikkből pedig az jött le, hogy Linus szerint az, holott a kdump része a kernelnek (a weblapja szerint).
Ha arról menne a vita, hogy alapértelmezésként legyen-e ilyen más kérdés, mint ha arról, hogy egyáltalán legyen-e ilyen.

Nem teljesen világos, hogy akkor most min is kínlódik a kövér pingvin.

nekem ez az egesz ugy jott le, hogy azert szar mert nem arra valo amire a linuxot o elkepzeli. mintha semmilyen teren nem gondolkodna abban, hogy a linuxot esetleg celhardveren es nagyvallalati kontrollalt kornyezetben is hasznalhatnak. mintha csak a windows egysegsugaru usereinel egy fokkal magasabb szinten levo, mar a linux-szal is ugy ahogy elboldogulo felhasznalok erdekelnek. ugyanis akkor tenyleg szinte semmi ertelme nincs, az a par ember akinek kell, az hasznalhatja most is.

ugy tunik, hogy Torvalds is azon emberek koze tartozik akinek ha valamifele ellenvetese van barmi ellen azt mindenkeppen vulgarisan is kinyilvanitja ami talan annyira nem szerencses mint amilyen hatasos vitaindito. tapasztalataim szerint egy jol megfogalmazott es felepitett hozzaszolasra sokkal kevesebb reakcio erkezik mint egy olyanra hogy ez vagy az szar mert ez igy meg igy van. lehet, hogy az informaciotartalma bitre pontosan ugyanannyi a ket hozzaszolasnak, megis ha anyazas van akkor hamar beindul a flame. az emberi termeszet furcsasagai. Mindenesetre azzal egyetertek, hogy ahogy a winben is kikapcsolom a szar dumpot ugy ott se foglalkoznek vele egy sima otthoni gepen ami tokeletesen elegendo ha 99%osan mukodik, es evente egyszer buheralni kell. hogy ez atlag linux szervereknel mennyire van igy, azt sajna nem tudom. annyit csak hogy ketfajta linux szervert ismerek. az egyik amelyiknel nem ert hozza a rendszergazda es idokozonkent szinte windows szeruen reinstall van. a masik tipusnal ert hozza a rendszergazda es ezekkel sosincs semmi baj. vagyis biztos van, de az altalam ismert szerverekkel nem fordult elo meg semmi

Ha elolvasod, hogy milyen szálra válaszoltál, akkor rájössz, hogy honnan jött ide a Microsoft. Azt hittem - szerintem joggal -, hogy arra reagáltál. A dump-ok elemzése a fejlesztők munkája többnyire. Microsoft OS és dump esetén a Microsoft a fejlesztő. Gondolom jó pénz (támogatási szerződés, jó partnerség, stb.) fejében elemzi neked is. Így megfelel?

--
trey @ gépház

Pistike tehát kér resetgombnyomást, kernelt upgrade-el és reménykedik, hogy az az ismeretlen hiba, ami mindig akkor üt be, amikor ő nem szívesen foglalkozna a géppel abban már elmúlt.

A frankó megoldás, hogy a kernel a RAM-ban hagy egy bugreport-ot, esetleg egy kis backtrace-t, amit RESET gomb után még megtalál. Nem tudom, hogy ezt a megoldást bármelyik kernel támogatja-e.

Amúgy a reiserFS-es fagyás nem életszerű példa, mert a reiser nem szokott menet közben fagyni. Csak más fagyások utáni journal replay-be szokott belehalni.
Tapasztalataim szerint mostanság leginkább driver-hiba vagy egyenesen HW-hiba miatt szokott a kernel megállni (ld. sata_nv). Ilyenkor pedig a crashdump sem megy (ld. sata_nv).

Ez a megoldás szerintem csak akkor életképes, ha a kerneltől majdnemhogy függetlenül futkározik vmi alkernel vagy nemtom hogy lehetne hívni, ami ilyes esetben biztonsággal tud írni a lemezre. A gond ott kezdődik, hogy a sok FS miatt kellenek bele driverek, amik persze a kernelben vannak, és innentől kezdve ott tartunk szinte, hogy két kernel fut, egy alap és egy kicsi csak a crashdumpnak.
Azért lehet hogy van olyan környezet, ahol ezt megérné használni, mai HW-ek mellett, nem olyan lehetetlen feladat egy ilyet futtatni.

"Dumpolni, csak erre es erre lehet, es kesz." Ez már feltételezem belefér a "kontrollált környeztbe", amire Linus is azt mondta, hogy van létjogosultsága a crashdump-nak. Arra gondolj, hogy mondjuk egy Linux-ot futtató notebook esetén hova / mire dump-olsz. Marad az egy szem diszk, egy szem swap. Ha szerencséd van, nem lesz semmi probléma.

--
trey @ gépház

Megint itt vagyunk, hogy vagy mukodik, vagy nem, ha szerencsed van, es mukodik, akkor hasznos. Ha nincs, akkor igyis ugyis volt egy OOPS-od, ez meg a swap particiod is szetcsapta, na bumm. Nyilvan ha erzekeny informaciok lehetnek benne akkor ki kell kapcsolni, vagy nem kell elkuldeni a fejlesztoknek.

Normalisan megcsinalva nincs. Mondjuk kinyomja valamilyen formatumban a swap particio elejere - azt azert eleg egyszeruen ki lehet talalni, hogy melyik swap particio, bar a regi Solaris x86 particiokra veszeles lehet:) - a tobbi particiohoz meg nem nyul. Bootkor, amikor pl megnezi, hogy hibernalva volt e gep, es visszatolja a RAM tartalmat swaprol, akkor megnezheti, hogy volt e crash dump. Annyira bonyolult ilyenkor csak az egyik particiora irni? Jo, mondjuk ha olyan driver bugos, akkor igen, de ilyenkor ismet csak nem kene csinalni, es az osszes tobbi nem disk-related bugnal jol jonne.

Es meg ilyenkor is, ha felsz tole, akkor kikapcsolod az egeszet.

Errol beszelek. Mit vesztunk azzal, hogyha a dump miatt inkonzisztens lesz a swap tartalma? Semmit, szerintem kovetkezo bootkor el lehet dobni, arrol beszeltem, hogy ilyenkor nem sikerul a dump. A "na bumm" azt akarta jelenteni, hogy a swap particio a dump irasa kozben inkonzisztens lesz, akkor nincs semmi, csak nem sikerult, es kesz.

"Csak a disk (network, serial) driver kell hogy működjön."

Csak a disk driver kell, hogy __jól__ működjön. Aztán ha nem, és random összfirkálja a disk-et, akkor "pusztul-burul" minden filerendszerestül / swap-ostul.

Van erre esély? Ez lett volna a kérdés, és nem az, hogy mi lesz a swap belsejében.

--
trey @ gépház

"Aztán ha nem, és random összfirkálja a disk-et, akkor "pusztul-burul" minden filerendszerestül / swap-ostul."
Így van, egy rosszul felparaméterezett hdparm hívás éppen elegendő ehhez.
---
Sok gyerekkel ellentétben én sose akartam tűzoltó lenni. Lettem helyette informatikus. Nem találjátok ki, hogy mit csinálok nap mint nap...

Azert nezzel mar ki annyi inteligenciat azokbol a kurva BSD developerekbol - akik mar javareszt akkor kernelt hekkelgettek, mikor a kulonbozo Usenet-en meg csak fercelt hir volt Linux megjelenese - hogy azt a kibaszott if-et nem felejtettek ki a kodbol, ami a dump es a swap meretet komparalja. Gyanitom nem veletlen alakult ki az a nezet, hogy a swap meretet (ha van), akkor illik minimum a memoria meretenek duplajara allitani. Nem mindenhol divat az az osszefosott kod, mint ami a linux kernelben van. Most epp azon rohogunk, hogy a linux kernelt meg lehet boritani egy-egy jol formazott SCTP csomag halmazzal IPv6-on. 2.6.21.1-ig bezarolag. Kellemes kernel panic jellemzi a dolgot, ugy, hogy meg a memoriaban levo cache-ket sem kepes szinkronizalni a lemezekkel.

---
pontscho / fresh!mindworkz

Nem mindenhol divat az az osszefosott kod, mint ami a linux kernelben van. Most epp azon rohogunk, hogy a linux kernelt meg lehet boritani egy-egy jol formazott SCTP csomag halmazzal IPv6-on. 2.6.21.1-ig bezarolag. Kellemes kernel panic jellemzi a dolgot, ugy, hogy meg a memoriaban levo cache-ket sem kepes szinkronizalni a lemezekkel.

IPv6 nem elterjedt. 95 körül ugyanúgy meg lehetett borítani a híres-neves BSD leszármazott Solaris 2.5-öt egy Ping of Death-el, mint a LOL kategória Win95-öt, vagy az OS/2-t. Szóval hibák lehetnek akár egy évtizedes kódban is, nemhogy egy viszonylag friss kódban. Majd ha sűrűn használják, jönnek a bugreportok is és javul a kód minősége. Dehát értem én, csakazértis linux suxx...

init();

IPv6 nem elterjedt

Az a baj, hogy bizonyos rovid tavu, de nagy hordereju projektek alapjat ez kepezi, igy eleg relevans es a project budzseben nem szerepel a linux kernel foltozasra szant ido. Report utan meg vagy fixaljak, vagy nem, mindenesetre ilyen ketes kimenetelu bugreport nem megfelelo eljarasmod. Kulon vicc, h kulso fejlesztesu mobil IPv6 stack-et kell belepecselni, h valami effektiv munkat is vegezzen. Mar csak halkan szoktam vigyorogni, mikor a szemben levo munkaallomason dolgozo kollega a hajat tepi linux kernel devel kozben. :) Hal'sten en ezt most megusztam.

Ja! IPv4-en is elpanikol 2.6.21.3-ig bezarolag. Ciki.

95 körül ugyanúgy meg lehetett borítani a híres-neves BSD leszármazott Solaris 2.5-öt egy Ping of Death-el, mint a LOL kategória Win95-öt

Anno mi egy megat dumpoltunk a /dev/random-bol a w9x 135 v. 139-es portjara (nem emlekszem mar ra pontosan), es figyeltuk milyen alomszepen kezd instabilla valni.

---
pontscho / fresh!mindworkz

Elfogadom (és sokszor tapasztalom is), hogy a linux kernel rossz minőségű (szerencsére nekem Linux kernelhez nem kell nyúlnom)...

Az a baj, hogy bizonyos rovid tavu, de nagy hordereju projektek alapjat ez kepezi, igy eleg relevans es a project budzseben nem szerepel a linux kernel foltozasra szant ido. Report utan meg vagy fixaljak, vagy nem, mindenesetre ilyen ketes kimenetelu bugreport nem megfelelo eljarasmod. Kulon vicc, h kulso fejlesztesu mobil IPv6 stack-et kell belepecselni, h valami effektiv munkat is vegezzen.

...de akkor végülis miért nem valamilyen BSD-t használtok? (akár OpenSolaris-t?)

Ja! IPv4-en is elpanikol 2.6.21.3-ig bezarolag. Ciki.

Ez több mint ciki. Ez szomorú.

Anno mi egy megat dumpoltunk a /dev/random-bol a w9x 135 v. 139-es portjara (nem emlekszem mar ra pontosan), es figyeltuk milyen alomszepen kezd instabilla valni.

A példát csak szemléltetésül írtam, hogy egy kipróbáltnak hitt kódban (akkor kb. 10 éves Solaris TCP/IP stack) sem bízhat igazán az ember, ha még oly' BSD akkor sem.

[offtopic]
Persze láttam én már megdögleni SVR4 Unix származék rendszert is (UNISYS) attól, ha a VT100 terminálon egy "cat unload.txt"-t (ahol az unload.txt legalább 30-40 MB méretű) nem vezették bele pg-be, hanem hagyták, hogy a terminálra hányja a sorokat. Ettől garantált volt a kernel panic (!). Nyilván valamilyen driver hiba lehetett, a terminálok egy aszinkron terminál-szerveren keresztül kapcsolódtak a géphez. Ebből is látszik, hogy a monolitikus felépítés milyen szuper :)
[/offtopic]

init();

...de akkor végülis miért nem valamilyen BSD-t használtok? (akár OpenSolaris-t?)

Mi L4-et vagy valamely BSD-t preferaltuk anno, de a vegso dontest nem mi hoztuk meg.

Ja! IPv4-en is elpanikol 2.6.21.3-ig bezarolag. Ciki.

Ez több mint ciki. Ez szomorú.

Az. El sem merem kepzelni milyen tesztelesen esett at a kerdeses modul, mert raadasul semmi extra nem kell a reprodukciohoz.

Ebből is látszik, hogy a monolitikus felépítés milyen szuper :)

Pszt, ezert errefele megkoveznek. :)

---
pontscho / fresh!mindworkz

> IPv6 nem elterjedt

Muhaha.

Linuxon kivul az osszes tobbi letezo mainstream OS (VMS, Tru64, OSX, *BSD, Win, etc) mar evek ota default IPv6 tamogatassal indit. Ezen az L betuvel kezdodo fostengeren meg ma is problema az IPv6, lasd PCMCIA wifi, vagy egey virtualis layer2 interface. Es nem azert, mert bleeding edge lenne. Ezek alap dolgok portable es corporate kornyezetben. Ezekbe olyan szepen deadlockol IPv6-tal a linuz (lattam ubuntun es centoson is), hogy csak magic sysrq-val lehet force rebootolni. Linuz kb 5 evvel van lemaradva a piactol ebben is, koszonhetoen az idiotaknak akik "fejlesztik".

--
the multiply techbanned hup user

...osszes tobbi letezo mainstream OS (VMS, Tru64...

LOL

L betuvel kezdodo fostengeren meg ma is problema az IPv6

Elhiszem, ahogy Pontschonak írt válaszomban írtam is. De az állításom továbbra is fenntartom: az IPv6 nem elterjedt. Akkor lesz elterjedt, ha majd otthon, az internetszolgáltatódhoz IPv6-on kapcsolódsz, az pedig akkor lesz, ha a valóban mainstream OS (Windows és annak is a Vista változata) fog futni az otthoni gépek nagyrészén és a szolgáltatók lehetővé teszik, hogy a beépített default IPv6-ot kihasználd.

init();

Akkor ezek szerint a kernel kozel 15%-at ne akarja senkise hasznalni, mert az mind EXPERIMENTAL, sot, nemelyik evek ota az, de ha nem hasznalod csak a sajat eleted nehezited meg ?

Upd: par kiragadott pelda:

"PPP over Ethernet (EXPERIMENTAL)"
"RAID-10 (mirrored striping) mode (EXPERIMENTAL)"
"Plug and Play BIOS support (EXPERIMENTAL)"
"Boot from EFI support (EXPERIMENTAL)"
"Intel 810/815 support (EXPERIMENTAL)"
"Intel 830M/845G/852GM/855GM/865G support (EXPERIMENTAL)"

Ezek azert 2007-ben eleg elterjedt dolgok. Plane a pppoe. De az EXPERIMENTAL az nem szamit es az Intel tamogatja a linuxot! :)

---
pontscho / fresh!mindworkz

Senki nem mondta, hogy ne használd, viszont ha használod, akkor ne pattogj hogy szar, hanem küldj patch-et. (vagy legalább ne itt sírj hogy szar, mert itt k*** senki nem fog ezen segíteni) Vagy a legegyszerűbb megoldás: használj mást.

Pppoe-et tudsz a fent említett driver nélkül is használni.

Nem mintha magyarazkodnom kellene neked, de azert par dolgot tisztazzunk. Peldakent hoztam fel azt a bugot, nem a hiszti volt a cel, es valahogy eszembe se jutott, hogy majd a melyen tisztelt hupperek kozul (tisztelet a kivetelnek, van a brigadban olyan arc, aki megtudna tenni) fogja barki is fixalni.

Ujabban marha nagy divat lett itt az, hogy "a linuxot ingyen csinaljak NEKED", akkor kezem labam keresztbe rakva, fulem farkam behuzva orvendezzek, hogy "igen! megcsinaltuk!". De ha az ember kritikaval meri illetni akkor azonnal jon a "nem tetszik? irj jobbat!", "bugos? pecseld meg!". Bravo, ha a megrendelo fele ilyen magatartast tanusitanek, azt hiszem kurva hamar ledobnam a sulyfeleslegem. Attol, hogy opensource nem egy divatdiktatura szerepet kellene magara vennie, mint ahogy az sok esetben tapasztalja az ember.

Es igen, pattogni fogok, ha ugy hozza kedvem, mint te. Es nem fogok mast hasznalni, ha egyszer azt a szart MUSZAJ. De ugy tunik szamodra az olvasas jelent problemat.

Uff.

---
pontscho / fresh!mindworkz

"De ha az ember kritikaval meri illetni akkor azonnal jon a "nem tetszik? irj jobbat!", "bugos? pecseld meg!"."

Valami hasonló stílus volt jellemző a nagyszerű MPlayer team-re is. Volt az embereknek honnan tanulni.

"Es nem fogok mast hasznalni, ha egyszer azt a szart MUSZAJ."

Nem, nem muszáj.

--
trey @ gépház

"De ha az ember kritikaval meri illetni akkor azonnal jon a "nem tetszik? irj jobbat!", "bugos? pecseld meg!"."

Valami hasonló stílus volt jellemző a nagyszerű MPlayer team-re is. Volt az embereknek honnan tanulni.

Teny. Az is, hogy ez a resze (PR) mar akkor sem erdekelt. Nem is csinaltam.

"Es nem fogok mast hasznalni, ha egyszer azt a szart MUSZAJ."

Nem, nem muszáj.

Mar leirtam egyszer, hogy miert muszaj.

---
pontscho / fresh!mindworkz

Ujabban marha nagy divat lett itt az, hogy "a linuxot ingyen csinaljak NEKED", akkor kezem labam keresztbe rakva, fulem farkam behuzva orvendezzek, hogy "igen! megcsinaltuk!". De ha az ember kritikaval meri illetni akkor azonnal jon a "nem tetszik? irj jobbat!", "bugos? pecseld meg!".

hmm, ez tenyleg igy van

monduk a sokan jonnek vele, hogy az oss igy meg ugy, de egy gramm stuffot nem tolnanak be a kozosbe

--
The Internet has evolved from smart people in front of dumb terminals to dumb people in front of smart terminals.

Ket problemam van ezzel:

Egyreszt elfregmentalodik a sok forktol a fejlesztoi bazis, es lesz egy csomo jobb esetben felkesz cucc, es egyik sem tud semmit. Tele van veluk a SourceForge. Arrol nem beszelve, hogy ezek a fejlesztoi bazisok onszervezodoek, amik kozponti iranyitas, tervezes es teszteles nelkul "termelnek", aminek a minoseget meg sokat tapasztaltuk mar. (Persze ez nem csak az opensource developmentre igaz, de itt a leglatvanyosabb). Szerintem ez az elony epp ugy hatranya is.

Masreszt ezt a "szlogent" altalaban pont azok vagjak az emberhez, akiknek csak a szaja jar.

---
pontscho / fresh!mindworkz

"Egyreszt elfregmentalodik a sok forktol a fejlesztoi bazis, es lesz egy csomo jobb esetben felkesz cucc, es egyik sem tud semmit."

Nem feltétlenül kell fork-olni. Be lehet dolgozni az eredeti projektbe is. Van akinek sikerül.

"aminek a minoseget meg sokat tapasztaltuk mar"

Pluszban és minuszban is.

"Szerintem ez az elony epp ugy hatranya is."

Általában az éremnek két oldala van.

"Masreszt ezt a "szlogent" altalaban pont azok vagjak az emberhez, akiknek csak a szaja jar."

Ettől még igaz lehet.

--
trey @ gépház

azt hiszem en ertettem felre valamit, vagy ti engem:

"ezt a "szlogent" altalaban pont azok vagjak az emberhez, akiknek csak a szaja jar."

nekem ez jott le abbol, amit Pontscho irt, erre bologattam :)

az oss nagyon jo dolog (szerintem termeszetesnek kellene lennie, hogy elerheto a forras, meg ha nem is felhasznalhato licenc nelkul), de nem mindenaron

--
The Internet has evolved from smart people in front of dumb terminals to dumb people in front of smart terminals.

Elnézést, de lehet attól valamit negatív kritikával illetni, hogy FLOSS. Én is szoktam kritizálni a Linuxot, de mindig hozzá is teszem, hogy ingyen van, tehát nem kell elvárni, hogy egy Windows- vagy OSX-alternatívát nyújtson nekem. Igen, reszelni kell, konzolban szerkesztgetni stb.
De attól, hogy ingyen van, még illetheti kritika. Lassan már olyan lesz az egész, mint a "Mi folyik Gyöngyösön?"-videó.
--
'Please, just tell people to use Windows.' - Linus Torvalds on KDE and GNOME
Registered M$funboy #006 (vigyázat: memetikai dágvány!!!11)

A különbség közted és azok között, akik ezt a módszert lehet, hogy régebb óta használják, mint hogy te élnél az, hogy te elméletekről beszélsz, ők pedig megírták és működik.
Természetesen semmi sem gátol meg abban, hogy akár külön diszkre dumpolj, ha neked ez szimpatikusabb.

( sartek | 2007. 05. 26., szo – 10:59 )

a Solaris hasznalja a crashdump-ot meg ezeket.
a Linux fenykepezget stb

de vajon melyik hatekonyabb? ersd: melyik rendszer a stabilabb? melyikbe van kevesebb bug?

Nem, arról 91-ben nem igazán tudtam még. :)

93-94-ben esetleg? Franc sem emlékszik már. Csak azt tudom, hogy nem volt 3,5-es floppym, ezért valami ismerőssel írattam ki 5,25-ösre. Az rémlik, hogy 26 lemez volt a cucc (de hogy melyik, arra már nem emlékszem, cserébe lehet, hogy még megvannak, csak már nincs mivel olvasnom őket :) és mindig valamelyik utolsónál volt read error, de mindig másiknál. Kurva idegesítő volt, de végül csak sikerült feltolni. :)
Ja és mintha karácsony lett volna.

Mindig is éreztem, hogy naplót kellene vezetnem.

"Tán mer negyedannyi feature se nincs benne. "

A számból vetted ki a szót. Bár én a tizedét mondtam volna. A Solaris 3-4 támogatott architektúráját a Linux mit tudom én 50+ (tippeltem) arch-jával szemben. Érdekes összehasonlítás lenne. Kb. mint az almát a lófaszhoz :))

--
trey @ gépház

"Bár ami igazán sokplatformos az a mindenki által sokplatformosként ismert netbsd, aszongyák a nagyok."

Azt is mondják, hogy a Linux kernel lassan ugyanannyi platformot támogat (ha nem többet), mint a NetBSD. Nem néztem utána. Meg kéne nézni.

--
trey @ gépház

Linux:

Compaq Alpha AXP, Sun SPARC and UltraSPARC, Motorola 68000, PowerPC, ARM, Hitachi SuperH, IBM S/390, MIPS, HP PA-RISC, Intel IA-64, DEC VAX, AMD x86-64, AXIS CRIS, Renesas M32R, and Atmel AVR32

(kernel.org)

NetBSD:

acorn26 acorn32 algor alpha amd64 amiga amigappc arc arm32 atari bebox cats cesfic cobalt dreamcast evbarm evbmips evbppc evbsh3 ews4800mips hp300 hp700 hpcarm hpcmips hpcsh i386 ibmnws iyonix landisk luna68k mac68k macppc mipsco mmeye mvme68k mvmeppc netwinder news68k newsmips next68k ofppc pc532 playstation2 pmax pmppc prep sandpoint sbmips sgimips sh3 shark sparc sparc64 sun2 sun3 vax x68k xen zaurus

(netbsd.org)

aztan ki tudja, hogy melyik mukodik valojaban :P
linuxnal meg az a kerdes is fenn all, hogy letezik-e (up to date) disztro az osszeshez, vagy from scratch kell megoldanod :)

szoval ez nem igazan jelent semmit, hogy mennyit tamogat (kiveve ha van valami elokukazott hardvered, de production rendszert ritkan telepit az ember a helyi egyetemrol leselejtesett sgi gepre)

viszont linuxnak van egy mmu nelkul is mukodo forkja, ami netbsd-nek nincs

jajj, de ez mar nagyon offtopic :)

--
The Internet has evolved from smart people in front of dumb terminals to dumb people in front of smart terminals.

igazabol ezt akartam bemasolni, mert vegul is az szamit, hogy a mainline kodban mi van benne, csak nem talaltam meg, hogy lehetne megnezni a git webfeluleten, mint itt. a tarball-t meg nem akartam csak ezert letolteni :P

de meg mindig tartom magam ahhoz, hogy a tamogatott platformok szama nem teszi se jobba, se rosszabba a rendszert :)

--
The Internet has evolved from smart people in front of dumb terminals to dumb people in front of smart terminals.

( petya | 2007. 05. 26., szo – 11:01 )

X86ra mar raferne valami normalisabb a BIOS helyett, akkor nem lennenek ilyen problemak. Jobban kene eroltetni ezt az EFI temat, ha mar van. A fenykepezogepes megoldas rohejes, de ha erre van igeny, akkor Solaris/SPARC-on is megkapod a fenykepezheto temat is (ha monitor van a gepen, egyebkent soros konzolra kapod) a crash dump mellett.

A fényképezőgép témát nyilván félig viccesen, félig mint utolsó megoldást említette olyan skill-telen emberek számára, akik mondjuk nem tudnak összeállítani egy normális debug környezetet (soros port + kermit, OOPS üzenetek elkapása hálózaton keresztül, stb.), de rendelkeznek olyan uniq hardverrel, ami miatt a fejlesztőknek hasznos lehet az infó. Kár lenne ezt meglovagolni. Küldtem már be FreeBSD-nek és DragonFly BSD-nek is fényképet képernyőről, mert hétvégén kellett egy notebook-ot debug-olni otthon, ami se soros port, se semmi más nem volt elérhető. Egyszerűen nem volt más lehetőség. Mégis hasznos volt.

--
trey @ gépház

Ez oke, de pont notebookon debugolaskor valoszinu a fejlesztok is jobban orulnenek normalis dumpnak. Ertem en, valahol problema ha ilyen van, Solarison is kikapcsolhato. Nem meglovagolni akartam a fenykepezos temat, hanem azt mondani, hogy a kontrollaltabb kornyezetet BIOS replacementtel valamilyen szinten meg lehetne csinalni.

itt jöhetne a képbe ez, ezzel egy kis fejlesztés árán el tudnának jutni a kivánt célig
__________________________________________________________________

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

erre irtam a linket kettövel feljebb ami a linuxbios.org -ra dob. Mert látok benne jövöt, csak még nem támogatja az alaplapomat és jelenleg több nagyobb cég is alkalmazza, többek között a tyan ami azért spéci server cuccokat gyárt

__________________________________________________________________

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

( Hunger | 2007. 05. 26., szo – 11:11 )

Alan Cox egyetértett Linus-szal. Szerinte további probléma a crashdump-okkal, hogy azok érzékeny információkat tartalmazhatnak

Szerintem meg egy sima Oops is tartalmazhat ilyet. :)

( ng | 2007. 05. 26., szo – 11:50 )

Wazze, ilyenen vitatkozni.. Ilyenen gondolkozni!!! Ne má..
---
Mushroom mushroom..

( dc | 2007. 05. 26., szo – 13:54 )

Kis javitas a dump file-ok helyehez, a /var/crash/"nodename"-be rakja a vmcore.# -t es a unix.#-t. Azzal hogy ezek a dump-ok erzekeny info-t tartalmazhatnak, egyetertek. En azonban szemely szerint orulnek neki ha binux alatt is lenne mod egy ilyen kellemesen allithato (dumpadm) crashdump funkcio, nem is beszelve a coreadm-rol. A crashdump supportot attol meg bele lehetne rakni a kernelbe, egy alapertelmezett `nem keszitek dump-ot'-tal.

"A crashdump supportot attol meg bele lehetne rakni a kernelbe, egy alapertelmezett `nem keszitek dump-ot'-tal."

ez igy van, ha valakinek kell, akkor valalja a feleloseget, es bekapcsolja. persze, lehet, hogy crashnel pont hulyeseggeket fog irni, de ez akar egy normalisan kernelben is elofordulhat. 2.4 2.6
ha elbreakeli neki a dump az fs-t, akkor igy jart, de hibakereses elott illik backupolni, ha lehet.

masik erdekesseg, hogy linus nem reg ugyanezt a gondolkodasmodot kifogasolta a gnome-nal, hogy amire a fejlesztok ugy gondoljak, hogy hulyeseg, azt egyszeruen nem rakjak bele. erre most pont ezzel jon o is...

freebsd-nel alapbol be van kapcsolva, de nem tudom mi a francnak, mikor nem csomagoltak melle kernel.debug-ot... (6.2)

--
The Internet has evolved from smart people in front of dumb terminals to dumb people in front of smart terminals.

"linus nem reg ugyanezt a gondolkodasmodot kifogasolta a gnome-nal, hogy amire a fejlesztok ugy gondoljak, hogy hulyeseg, azt egyszeruen nem rakjak bele"

Nem egeszen. O azt kifogasolta, hogy amire a gnome fejlesztok ugy gondoltak, hogy bonyolult, es az emberek "hulyek" hozza hogy hasznalni tudjak, azt hagyjak ki.
-------------------------------------

|^^^^^^^^^^^^^^^| ||
|...BEER TRUCK..........| ||'|";, ___.
|_..._..._______===|=||_|__|......, ] -
"(@)'(@)"""**|(@)(@)*** **''(@)

( sj | 2007. 05. 26., szo – 14:17 )

"Solaris szar"

A Linuxot szeretem, de Torvalds( modora)rol mar sok rosszat hallottam, +1.

ASK Me No Questions, I'll Tell You No Lies

( wELDER v | 2007. 05. 26., szo – 17:30 )

hát én nem szeretnék hiba esetén lemezre író kernelt,
a problémák 99%-át nálunk ram hiba okozza,
akkor meg mindegy raktak-e if -et bele a fejlesztők,
bármit csinálhat, persze amilyen szerencsés vok,
a hdd-re író kód biztos működne, csak a cél változna...

Szerinted ha ilyet tud a kernel produkálni abban a pici kódban, ami a memóriatartalmat kitolja diszkre, mekkora eséllyel fordulhat elő ugyanez a kód többi részén?
Azaz mennyi esélyt látsz arra, hogy még azelőtt szarrá vágja az összes resizerfs (sic) partíciódat, mielőtt még kilőné a reaktormagot?

( saabi v | 2007. 05. 26., szo – 21:24 )

Mi marhák meg csak analizáljuk a dumpokat és megmondjuk az ügyfélnek, miért szállt el a rendszere. Persze meg is javítjuk. Igaz, nem GNU/Linux-ról van szó.
De most már tudom, hogy ez hülyeség. :D

Ave, Saabi.

A HP-UX "kontrollált környezetben" fut. Arra nem mondta, hogy hülyeség.

"Yes, in a controlled environment, dumping the whole memory image to disk may be the right thing to do."

A Solaris esetén is csak arra a Solaris-ra értette, amit felteszel mindenféle gépre. Éppen azért, mert a Linux erőssége az, hogy "mindenféle gépen" fut, nem jó megközelítés szerinte ez a dump-olás.

Az baj itt az emberekkel, hogy a belinkelt dolgokat nem nagyon olvassák el. Pedig el kéne...

--
trey @ gépház

IMHO a dump "must have"!
Kaptunk már lniux-os "screenshot"-ot, hogy analizáljuk. Hetekig röhögtünk rajta. Enterprise környezetben igenis szükséges annak ismerete, hogy miért durrant el az adott gép. A crashdump nem a rendszergazdának készül, hanem a supportosnak. Tehát az nem indok, hogy a rendszergazda nem tudja análisan izélni.

Ave, Saabi.

Ne légy már ilyen egyszerű, a fényképeken röhögtünk. Merthogy a "screenshot"-ok egy digikamerával készültek.
Hogy a Sun support mennyire büszke magára, elképzelésem sincs. Annak meg hogy
ti miképp analizáljátok a cuccaitokat, mi köze a crashdump kérdésköréhez?

Ave, Saabi.