Vlákno názorů k článku
Opravuje se lépe Linux nebo Windows?
od jd - Kdyby windows mely:
- strace,
- sytemove logy na urovni...
-
jd (neregistrovaný)
Kdyby windows mely:
- strace,
- sytemove logy na urovni linuxu,
- pouzitelne hlaseni o padu aplikace (ne jen hromadu cisel, hodilo by se minimalne jmeno vlakna co spadlo)
- moznost sledovat zaznam bootu na konzole kdyz se mu nabootovat nechce
- poznost prepnout na konzolu, kdyz nedokonci boot grafiky
Tak by tam neco spravit slo, jinak se jen zkousi co by to mohlo byt. Nikdy nezapomenu jak koncil boot zasekem diky vadnemu sektoru na disku. Pri presunu dat na novy disk se ukazalo, ze vadny sektor nebyl soucasti zadneho souboru a po kopii dat 1:1 to nabehlo bez problemu -
I tady přidám názor: Jsem si takřka jistý, že většinu těchto nástrojů Windows v nějaké podobě má. Problém je ten, že dnes se za administrátora Windows považuje každej, kdo umí myší klepnou na tlačítko Start!
Opak je pravdou – stejně jako expertní správce Un*xů ví své a umí zdiagnostikovat systém hodně detailně, tak i expertní správce Windows! Lidé, kteří potřebné nástroje neznají nebo neumí používat nejsou automaticky důkazem, že Windows jsou na diagnostiku nebo rekonstrukci mizerným OS, ale spíše tím, že je mnohem méně skutečných odborníků na Windows, než na Linux.
I když to dost možná také znamená jen to, že rádoby odborníci na Linux umí na (svých) diskuzních fórech „křičet“ hlasitěji, než skuteční odborníci na Windows ;) -
FAWN (neregistrovaný)
Jako windows admin, co kliká myší, musím říct: nemá. Hlavně nemá pořádné logování, eventlog ve windows se za to dá považovat stěží. Hlavní problém bývá zjistit, co a kde chybu způsobuje, nástroje na řešení pak jsou. Nicméně hlavní práce windows admina je zajistit, aby problém vůbec nenastaly. Jinak by pak jejich řešením mohl strávit zbytek času ve vesmíru.
-
Vím poměrně přesně, jak vypadají různé logy v Un*xech a jak pro Un*xy, tak pro Widle platí, že informativnost obsahu logů se liší od aplikace k aplikaci. Ani v nejmenším bych si netroufl a priori tvrdit, který je lepší.
A už vůbec bych si to netroufl tvrdit pro systémové logy. Zrovna Windows totiž do event logu zapisují skoro každý detail aktivity systému. Un*x naopak bývá ve výchozím nastavení relativně „skoupý na slovo“. S jedinou výjimkou – u bootu bývají Un*xy „ukecanější“ než Widle. To ale lze – pokud vím – snadno změnit bootovacími volbami Windows kernelu (čímž mj. reaguji na stížnost některého Windows „experta“, který zde toto Windows vytýkal). -
To je stále stejný lidský problém! Nenapadlo Vás, že Linuxový laik se bude úplně stejně obtížně orientovat v hláškách Linuxu jako Windows laik v hláškách Windows? A naopak – ten, kdo vidí Windows hlášky denně bude mít zatracené problémy „číst“ logy Linuxu?
Proč se, lidi, neumíte podívat na oba systémy z obou stran a aspoň s trochou objektivity??! Mj. i kvůli takovémuto (dalo by se asi říci i „zaslepeneckému“) chování uživatelů Linuxu, nemám dnes už tento systém moc v lásce, ačkoli jsem na něm kdysi jistém smyslu vyrostl… -
FAWN (neregistrovaný)
Souhlasím s tím, že Windows jsou do eventlogu „ukecané“, ale výpovědní hodnota zápisů je, a to zejména v případě chyb, docela nízká. Co byste například řekl na takový příklad z aplikačního eventlogu win serveru:
Nelze nalézt popis ID události ( 2004 ) ve zdroji ( WBLOGSVC ). Místní počítač možná nemá informace registru nebo soubory knihovny DLL se zprávami potřebné pro zobrazení zpráv ze vzdáleného počítače. K získání tohoto popisu můžete použít parametr /AUXSOURCE=flag. Další informace naleznete v nápovědě. Součástí události jsou následující informace: .
Pokud jde o bootlog, jsou Windows opravdu stručné, to vypadá takto:
Loaded driver \WINDOWS\system32\ntkrnlpa.exe
Loaded driver \WINDOWS\system32\hal.dll
Loaded driver \WINDOWS\system32\KDCOM.DLL
Loaded driver \WINDOWS\system32\BOOTVID.dll
Loaded driver ACPI.sys
Loaded driver \WINDOWS\System32\DRIVERS\WMILIB.SYS
Loaded driver pci.sys
Loaded driver isapnp.sys
… atd
A někde najednou výpis skončí protože systém restartuje. Samozřejmě je podezřelý poslední driver, ale to nakonec nemusí být ten, co způsobuje nebootující systém.
Stačí si na technet.ms přečíst Troubleshooting the Startup Process, doporučovaný postup je metodou pokus / omyl: identifikujte drivery, které lze zakázat – zakažte je všechny, identifikujte nepotřebné služby – zakažte je všechny atd. atd. Pak je po jednom povolujte – pomohlo / nepomohlo a tak dále. Vcelku asi 20 reboot do safe mode a zpět normal… Atd..
Bootlog se zapne buď přepínačem /BOOTLOG v boot.ini (nejlépe předem) nebo vybere po stisku F8 (XP a výše) -
Kaacz (neregistrovaný)
Pavel Švíka ti určitě rád rovnou z rukávu vysype přesný popis a význam obsahu v enentlogu, je to totiž triviálně jednoduché a více vypovídající než zmatené unixové logy. Je totiž lepší než technici MS, kteří nám po nějaké době řekli, ať jim ty eventlogy neposíláme, že jim to stejně nepomůže. :-)
-
A kde se ty nastroje tedy skryvaji? Proc je MS taji? Obcas pomuzou utilitky, ktere MS koupil od Sysinternals. Ale ve Wydlich je velke hovno, nechame-li stranou ping. I kdyz nainstalujete Resource Kit, je to porad bida. Ziskate sadu strasnych utilit typu „kazdypesjinaves“, u kterych se i help vyvolava „konzistentne“ vsemi moznymi zpusoby, ktere si autori dokazali vymyslet.
