Názory k článku
Microsoft zaslal 361 patchů do Linuxu 3.0

Oni s tím mají úspěch už dnes. Na Windows HPC Serveru můžete běžet Autodesk Maya, Autodesk 3ds Max, Pixar's RenderMan, ANSYS Mechanical HPC, Abaqus FEA, NAMD, MATLAB Distributed Computing Server, Numerix, MoSes a řadu dalších. Referencí je dlouhá řada. Nejsou to aplikace pro top500.org, ale zase je jich spousta.
http://www.microsoft.com/hpc/en/us/solutions/hpc-case-studies-graphic-design.aspx

A proto prevazna vetsina bank bezela na VAX/VMS systemech a ted prechazeji(uz davno jedou) na AIX.
Proto se Londynska burza presunula zpet na linux...
Kod jadra je dosti slusne udrzovany a hlavne docela dobre pochopitelny, rekl bych ze to ma urcitou vnitrni logiku.
Rekl bych ze to je jeden z nejkvalitneji udrzovanych projektu a naopak bych rekl ze to JE oslnive dilo. (je to samozrejme jen muj nazor, stejne tak jako je vas uplne opacny, ale uz jsem par zdrojaku videl a myslim si ze linux je jeden z mala kde nenarazite na prilis pras*ren)

Byla řeč o superpočítačích, výpočetních clusterech. To je pro banky poměrně nová věc, kterou nejspíš na VAX/VMS nikdy nejely.
Banky jely svého času na VAX/VMS a UNIXech, dnes jedou Windows a UNIXech. Příběh LSE nijak nesouvisí s kernelem OS.

Bylo by dost smutné, kdyby kód kernelu neměl vnitřní logiku :). Co je podle vás ten oslnivý faktor Linuxu? Je to jedna z mnoha variací na téma UNIX, což byl už v době vzniku Linuxu značně přežitý model. Implementace byla od začátku tragická. Mizerný driver model, x86-only kód (další fází bylo tzv. ifdef hell), features implementované podle manuálu komerčních UNIXů, občas za pomoci hlavičkových souborů a komentářů z kódu :) z jiných projektů.
"Chytrý design" se projevil třeba absencí threadingu, který se pak snažili dobastlit pomocí clone(). Výsledek? Použitelný threading se objevil v kernelu 2.6; a výsledek pořád nic moc ve srovnání se Solarisem nebo Windows.
A co třeba příšerná latency toho monolitického kernelu s BKL? Samozřejmě napsat nepreemptivní kernel s BKL je jenodušší - zamykat netřeba :). Jenže odstranit BKL, když na něj spoléhají miliony řádků kernel code, to je něco jiného. Co říkáte na takový preempt_count? Je to podle vás ukázka čistého designu, nebo čirá příšernost? A co říkáte na to, že BKL byl po 17(!) letech odstraněn, jen aby byl nahrazen jinými velkými locky (bkldev_mutex, BTM)? Za dalších 5-10 let se možná dočkáte opravdu preemptivního kernelu. Nebylo by lepší nejprve přemýšlet, a pak teprve začít psát? MS měl preemptivní kernel už v první verzi NT, dodatečné úsilí bylo minimální. Stačilo předem promyslet návrh, a ušetřila se dlouhá léta bastlení.
Další výtky lze mít k obsluze přerušení, správě paměti atd.

Něco málo o designu Linuxu:
http://groups.google.com/group/comp.os.minix/msg/b813d52cbc5a044b

Nektere veci ktere pisete jsou nejmin 10 let stare, to je jako bych porovnaval linux 3.0 s windows 95.
Oslniva vec na linuxu(kernelu) je(IMHO), ze bezi na temer vsech procesorech na kterych to ma alespon trosku cenu rozbihat a pokud mam naladu, tak si muzu dodelat podporu pro dalsi procesor a podobne. Cimz jsem vam trosku vyvratil ten x86-only model. I kdyz to bych odbihal od HPC.

Vy jste zacal o tom, ze HPC nejsou jen ty z top500, ale musel byste lhat sam sobe kdybyste tvrdil ze zastoupeni operacnich systemu v teto tabulce o necem nevypovida..
Navic bych rekl ze ve sve dobe byli VAX (stejne jako bankovni UNIX) systemy neco na zpusob HPC - melo to o hodne vyssi vykon nez bezne stolni pc a VAX byli clustrove stroje.
BTW: Rekl bych ze napriklad Londynska burza do HPC systemu bude taky spadat.

Co treba porovnat fork() namisto threadingu(vim ze to je uplne neco jineho, ale vyzdvihuji klady lin jako vy win).. Ne vlastne nemuzem, win zadny fork() nema..

Bohuzel jsem nemel to stesti podivat se do kodu windows(NT - ty starsi bych snad radsi ani videt nechtel) abych poznal ze cely linux-kernel je hrozne napsany a nema cenu nad nim nic vyvijet, coz by meli taky poznat firmy jako Google, HP :) , IBM a podobne male rybky v mori.

Nerikam ze vsechny veci v jadre maji cisty navrh a je to ten nejlepsi zpusob jak to udelat, ale existuje a funguje. Pokud nekdo prijde s lepsim postupem, tak se to muze zmenit. (v pripade BKL to trva "trosku dele" jenze to je pochopitelne vzhledem k provazanosti temer se vsim v jadre)

Jestlize maji Windows tak skvely multitasking jak pisete, proc pri vyndavani CD z mechaniky zatuhne na chvili cely system (nedej boze aby ste z toho CD/DVD cetli)?
Proc pokud urvete USB z portu ma to podobny nasledek(i kdyz je pravda ze tam to zaskobrtnuti systemu trva kratsi dobu)? Ze by nejaky Vetsi Zamek (tm)?
V linuxu vam na chvili prestane reagovat proces, ktery dane DVD/USB vyuziva, ale zbytek systemu je pouzitelny. Je to temer nepozorovatelny lag, ale je tam..

Ten odkaz ktery jste sem dal je z doby, kdy vznikalo uplne prvni jadro(20 let zpet :) ) - ale dekuju, nostalgicky sem zatlacil slzu v oku a vzpomnel si na doby kdy pro me byl tucnak jen srandovni ptak ve fraku.

Tenhle jev jsem nikdy neviděl. Možná jsou tam nějaké masivní resource leaks - když běží Firefox, lze to skoro čekat.

To může být například nějaká domršená shell extension. Když si poradíte s troubleshootingem Linuxu, tohle pro vás musí být hračka :). Na prvním místě si projdete Event Log, potom spustíte Performance Monitor a sesbíráte všechna data po dobu trvání problému, a data zanalyzujete. Tak můžete zjistit, že nějaký proces například žral po tu dobu CPU. Když to nepomůže, zapnete logování uživatelského prostředí, a analyzujete výsledný log file. Můžete zkusit logovat i přístupy k registry a FS pomocí příslušných nástrojů.
http://support.microsoft.com/kb/221833

A když nepomůže ani to, zkusíte jestli je problém reprodukovatelný na čisté instalaci (stačí na virtuálním stroji který stáhnete zdarma na webu MS). Zkusíte MS KB, Google, a pak už je čas položit dotaz na MS diskusních skupinách, nebo rovnou otevřít u MS support case.

Kernel Windows 95 nemá s Windows NT nic společného, je to jiný produkt. Navíc jsou Windows 95 novější než první verze NT (1995 vs 1993). To vidím jako dva dobré důvody, proč to vaše srovnání vůbec nesedí.
Ten x86-only model jste nijak nevyvrátil. Linux dnes běží na více platformách, ale původní návrh portabilní nebyl. To byla jedna z chyb návrhu. Důsledkem bylo (a asi nadále je) ifdef hell. Na okraj dodám, že zkompilovat kernel pro novou platformu není u slušně napsaného OS velký problém. Například Windows NT byly historicky k dispozici pro x86, MIPS, Alpha AXP, PowerPC, Itanium, x64 a nyní přibude nově ARM. Problém je mít pro novou platformu opravdu dobře odladěný kernel i zbytek systému, poskytovat podporu, vytvořit ekosystém dodavatelů HW, SW a služeb. Bez toho jde jen o černou díru na peníze. Například Linux pro PowerPC je v srovnání s x86 prakticky mrtvý.

Celkem jasně jsem psal, o čem zastoupení Linuxu v top500 vypovídá. Linux je zdarma, umí správu paměti, procesů, a má networking. Node výpočetního clusteru toho o moc víc umět nepotřebuje, a nulová cena je při vyšším počtu nodů velmi žádoucí.
HPC/supercomputing se tradičně zabývá výpočetně náročnými úlohami. Předpověď počasí, dynamika tekutin, vizualizace. V LSE jde o transaction processing, což je něco trochu jiného.

Windows mají fork() jenom pro POSIXové aplikace. Proč nemá Win32 fork()? To zjistíte, když srovnáte výkon fork() a threadingu na Linuxu. I s velmi průměrnou implementací threadingu je to mnohem výhodnější řešení, než fork(). Dalším průšvihem je správa paměti při používání fork(), která vedla na Linuxu k příšernosti eufemisticky zvané "late binding" (aka alokace paměti skoro vždy projde, i když paměť dávno není), což si vyžádalo vznik další příšernosti jménem OOM Killer (aka když nám lhaní o úspěšné alokaci paměti neprojde, tak vylosujeme nějaký proces a odstřelíme ho).

"Nerikam ze vsechny veci v jadre maji cisty navrh a je to ten nejlepsi zpusob jak to udelat, ale existuje a funguje. Pokud nekdo prijde s lepsim postupem, tak se to muze zmenit." - to je pěkně řečeno. Totéž lze napsat o Windows 95. Fakta jsou jasná: Linux není kvalitou implementace, natož návrhem, nijak zářivý. V řadě ohledů je na tom naopak velmi mizerně.

Mě Windows během vyndavání CD/DVD nemrznou, vyzkoušeno. U vás to může být problém HW. PATA kabel je pokud vím kompletně zablokovaný dokud zařízení nedokončí operaci. U SCSI mechanik se tohle nikdy nestávalo, protože SCSI podporuje asynchronní operace.
U odpojení USB zařízení jsem nepatrný lag našel, i když například zvuk jede dál. Podle mě půjde o nějakou reinicializaci USB HW. BTW historie podpory USB v Linuxu by vydala na dost drsnou kapitolu :)

Ano, ten odkaz je z doby vzniku Linuxu. Názorně ukazuje způsob návrhu kernelu, resp. absenci toho návrhu. Těch 17(!) let na alespoň částečné odstranění BKL je jen jeden z důsledků. Oni si všichni myslí, že se OS před každou major verzí komplet přepíše. To je ale omyl. Například většina toho co psal Mikuláš v tohle seriálu je dál pravda:
http://www.root.cz/serialy/porovnani-systemu-linux-a-freebsd/

Zajímalo by mě, jak řeší odlišnosti různých platforem Windows, když to není pomocí ifdefů ;-) Já to teda řeším C++ šablonami a jedním ifdefem nastavujícícm enum, ale i Windows jsou primárně v Céčku a assembleru…

Historicky Windows možná byly pro spoustu platforem, ale dneska už nejsou, mají spoustu x86-only kódu, kvůli kterým třeba spouštění UTC hodiny podporuje a je to dokumentovaná vlastnost, ale uspávání UTC hodiny úplně ignoruje, takže se rozhodí časové pásmo — tomu se říká bordel.

Aha, fork je strašný a ve Win32 záměrně neimplementovaný a proto Internet Explorer pomocí několika hacků něco jako fork používá pro oddělené taby, že? :-) Jinak smyslem forku není primárně výkon (který mimochodem jde pomocí forku a asynchronních operací udělat mnohem vyšší než u vláken, jak dokazuje třeba nginx), ale stabilita a robustnost.

Tím late binding asi máte na mysli overcommiting. Ten pro implementaci forku není potřeba a jde kdykoliv za běhu vypnout, pokud by vám vadil (a budete mít dost virtuální paměti). Pak se to bude chovat úplně stejně jako ve Windows. Protože však není tak špatný, jak tu tvrdíte (zřejmě je o dost lepší, než když Windows začnou rozšiřovat swap a výkon systému jde do háje), tak ho má naprostá většina počítačů zapnutý.

Windows mají Hardware Abstraction Layer (HAL), který řeší odlišnosti platforem.

Hodiny jsou maličká část HAL modulů. Hodiny v lokálním časové zóně (což je na PC standardní chování) udržují HAL moduly pro x86 BIOS PC a x86 ACPI PC. HAL pro Aplha AXP i pro EFI udržuje RTC v UTC.

MSIE nepoužívá fork(). Jinak fork() je katastrofa ohledně výkonu i správy paměti. A aplikační model založený na asynchronních událostech je na Windows léta masivně používaný; naopak aplikace (ani API) na UNIXech tradičně asynchronní nebývají.

Ano, overcommitting není pro fork() potřeba, a lze ho vypnout. Bohužel fork() vede k veliké spotřebě paměti, takže bez té overcommitting příšernosti vám paměť rychle dojde. V minulosti jsme to spolu diskutovali, a nemám náladu ani čas to absolvovat znovu.

Vážený pane, který se stydí za svojí skutečnou identitu, již dávno jsem Vám nabízel, že by byla zajímavá panelová diskuze na téma srovnání OS. To co zde předvádíte je dost ubohá demagogie a překrucování faktů.

Plně s Vámi souhlasím v tom, že přetažení Dave Cutlera z DECu byl mistrný tah MS a bez tato získaného týmu by MS zapadl stejně jako ZX-81. Souhlasím s tím, že tento člověk vyrostlý v inovativní firmě na VAXu a VMS dokázal navrhnout velmi kvalitní a stabilní model jádra NT s inovativně navrženým konceptem IRP, díky kterému jsou po roky drivery binárně (téměř) kompatibilní. Bohužel jako u většiny věcí, nad kterými převezme řízení vedení jdoucí za maximálními zisky bez osobního vtahu k inovacím, se postupně to, co bylo z DEC, Borlandu a jiných schváceno postupně kazí nabalováním zbytečných funkcí, zatěžujícího a škodlivého kódu pro omezování uživatele/kup­ce/majitele SW/HW (i když vlastně to poslední již MS ani neuznává).

Na Linuxovém jádru je pak velmi dobře vidět, že nadšení a nezmražení interních API propojujících jednotlivé subsystémy jádra může vést k vzniku moderního systému, kterému v mnoha ohledech nemůže systém se sice velmi kvalitním, ale 20 nezměněným konceptem, konkurovat. A to i přes to, že se Linux vyvíjel z relativně jednoduchého systému původně směřovaného na nešťastnou architekturu x86 i s částečným využitím segmentace, TSS a podobných zvěrstev. Soubory/disky byly nešťastně cachované na úrovni sektorů atd.

Současný design většiny subsystémů jádra se však posunul někam zcela jinam. Kombinuje koncepci spinlocků, mutexů s plnou podporou dědičnosti priorit a RCU tam, kde se jedná převážně o paralelní čtení z mnoha CPU. Vyladěním a volbou použití těchto principů podle způsobu využití dat v jednotlivých subsystémech je v současné době Linuxové nejspíš nejlépe šklálovatelným obecně použitelným a portovatelným operačním systémem na světě. Zvládá i single kernel image system s tisícovkami procesorů v NUMA systémech. Kolik je současný limit pro Win jádro? Myslím, že se Win svými cancelation locky a dalšími tradičními řešeními při větším počtu CPU musí skončit veškerý výkon na trashování cache.

Co se týče množství ifdefů, tak po přepsání jádra na generic IRQ, systém clockources, event devices atd. došlo k zásadnímu pročištění kódu a stlačení platformě závislého kódu na minimum i při podpoře desítek CPU architektur a stovek rozličných desek. A to od systémů s 8 MB RAM do systémů s TB paměti.

Současná správa fyzické paměti jako cache všech možných backing store přes na bázi page-cache je to nejlepší, co jsem měl možnost vidět. Schopnost sdílení stránek mezi procesy, COW, prohledávání d-cache založené na RCU jsou opět zásadní inovace o kterých si sytém (minimálně do nedávna) s pevným počtem předalokovaných prototype PTE položek pro sdílené stránky může jen nechat zdát. Kód Windows je sice vaším tajemstvím, ale omezení mnoha subsystémů danými nešťastně volenými externími a interními API systému Windows je jasně vidět i ve zdrojových kódech React OSu, vyvíjeného nadšenci pro Windows architekturu. Přitom tato koncepční omezení jsou pak při jejich znalosti dohledatelná i v poznámkách v dokumentaci Windows pro vývojáře. Když jsme u paměti, tak uznávám, že OOM killer není nic hezkého, jenže systém, který sdílí data a i anonymní VMA mezi procesy a dovoluje COW tak při konečné velikosti přiděleného odkládacího prostoru má možnost buď nesmyslně omezit počet spuštěných aplikací nebo se smířit s tím, že paměť dojde až později při zápisu. Mimochodem fork() na systému s dobře navrženým systémem pro reverzní mapování sdílených stránek (ne to ubohé PPTE) pak může být pro hromadu případů velká výhra. Například KDE aplikace mohou sdílet většinu neměnných inicializačních dat i v anonymní oblasti zaplněné při inicializaci prostředí. Přitom na rozdíl od vláken, pád jedné aplikace/okna nemá žádný vliv na paměť ostatních aplikací. Linux může mít i zpětnou kolekci/sjedno­cování stránek se shodným obsahem. Výkonnostně trochu sporná záležitost, ale pro virtualizaci opět často výhra. Koncept hypervisor-ops a KVM opět nejspíš předčí vše, s čím zatím přišel MS. Na Solaris zde zatím chybí dotažené jaily.

Co se odezev týče, tak bych se někdy rád dozvěděl reálná čísla z Windows. Moje zkušenost před lety byla tragická - drivery grafiky blokovaly i hard-IRQ na milisekundy. Ale uznávám, že to byla spíš záležitost driverů. S využitím různých berliček typu multimedia-timers se kolegům dařilo i před lety online zpracování obrazu a strefování se do rámců videosignálu - na dedikovaném počítači. Standardní Linux je na tom s průměrnou latencí podle mě lépe, koncept high resolution timers jde také dál. Maximální latence na tom však nejsou u normálního sestavení určeného na propustnost nijak dobře. Ani za desítku milisekund bych ruku do ohně nedal. Naopak postupně integrovaná podpora plné preemptce míří někam, kde Windows bez předražených řešeních na postavených nadřazených RT-kernelech/exe­cutivách nemohou uspět. 100 usec max latence jsou již velmi zajímavé.

Když si pak člověk v době 64-bit procesorů čte o 16-bit limitech ve Windows GUI na blogu "Pushing the Limits of Windows" od Marka Russinoviche, tak jen skřípe zuby, proč se pořád vývojáři musí trápit s produkty firmy, která musela být i k paskvilu jménem DPMI být dotlačena v době 386 jinými, protože prohlašovala, že 640 kB RAM a DOS stačí na věky.

Takže ze srovnání mi vychází jádro systému Linux jako inovativnější, škálovatelnější a zajímavější než NT 2011 a na základě způsobu vaší argumentace Vás považuji buď nedostatečně informovaného, slepě věřícího vlastním reklamním kampaním nebo za placeného demagoga.

S pozdravem, Pavel Píša

Pokud se nebojíte konfrontace s světovými odborníky v oblasti jádra Linux, tak mi napište na můj školní e-mail (snadno naleznete přes Google a možná i Bing) a pokusím se Vám osobní setkání s odborníky opravdový škálovatelný operační systém na podzim zařídit.

Celej tenhle thread je OT. Ale pravdepodobne jsi nikdy nevidel superpocitece od SGI. Bezi to na Linuxu na Itaniu a vice-mene je to krabicovy reseni vcetne kompilatoru, Matlabu, Fluenta, ...
Hadej na cem pocita treba Skodovka.

Škoda Auto má spoustu lidí se specializací na UNIX. Audi, IAM a SAIC jsou pro změnu referenční zákazníci na Windows HPC Server.
Krabicové řešení... Znáte Cray CX1?

Rozesmala me ta veta o udrzbe linuxu.
Pokud si pamatuji za poslednich 20 roku me praxe, tak unix/linux server se nainstaloval, nekam posadil, pustil a vic jsem o nem nevedel .. uptime 5 roku bezna vec. Pak vetsinou doslo k jeho stehovani nebo uz nebyl potreba nebo se upgradoval HW protoze se od toho chtelo neco vic.
Ale kolegove s windows servery kolem nich porade tancili obradne tance a furt neco resili. Minimalne ten restart jednou za mesic. No hlavne ze meli nejlepsi OS kterym byl uz NT. :-)

Další "výhodou" je únik těžkých kovů (včetně rtuti) z těch starých přístrojů.

Některé elektronky obsahují rtuť. Plus v celém zařízení najdete spousty kadmia, olova, fosforu atd. Určitě bych si sklad takových starých krámů nedělal v ložnici ani obýváku :), raději snad ve stodole.

To platí za ideálních podmínek, když ty staré krámy nejsou poškozené. V reálném světě se tady rozbije elektronka, tam kus něčeho odpadne, tuhle se něco obrousí...

Rozbije, odpadne, obrousí... To mluvíte o Windows, že? :-D

Novější verze Windows Serveru mohou běžet bez GUI, ale proč to proboha dělat? Omezovat správu systému na command line patří kamsi do minulého století (byť Windows bez GUI lze spravovat vzdáleně z GUI nástrojů). Navíc když to GUI zrovna nepoužíváte, tak "neškodně" leží někde na disku, a výkon nežere.

Správa systému v CLI patří kamsi do minulého století a proto novější verze Windows Serveru mohou běžet bez GUI. Proč jenom do toho ten MS investoval... Nebo že by je k tomu požadavky klientů donutily?

Třeba právě u těch výpočetních clusterů nemá GUI moc smysl. Nicméně naprostá většina zákazníků používá Windows Server klasicky s GUI. Osobně jsem žádný Windows server v produkci bez GUI ještě neviděl. Prostě není poptávka.

Windows (s GUI i bez) se dají spravovat vzdáleně pomocí těch samých nástrojů, jaké používáte lokálně. Prostě se na nějaké stanici či jiném serveru v daném admin nástroji připojíte ke vzdálenému stroji.

Nástroje používané pro desktopové verze Windows (Computer Management s disk managerem, Event Viewerem atd) fungují i pro připojení na server. Nástroje používané pro servery (například administrace Active Directory) si můžete zdarma stáhnout v balíku Remote Server Administration Tools. Celkem mě překvapuje, že tohle nevíte.

Změnilo se toho dost, ale Windows NT Server Tools for Windows NT Workstation byly zdarma i v době NT 4.0. MS byl i v té době známý velmi dobrými cenami. Mohl jste mít server na UNIXu, který jste kupoval div ne jako raketoplán (neexistovaly ceníky, o dodávce se dlouze jednalo, dodavatel rozdával "dárky", na server jste hrozně dlouho čekal), nebo stroj se stejným výkonem na Windows, který vás vyšel na desetinu ceny. Jako bonus jste dostal nižší cenu, daleko větší výběr SW, a snadnou administraci přes GUI. To proto jsou dnes všude Windows servery.

Vsichni spravuji windowsi servery pres gui, protoze to ani jinak nejde. Commandline nastroje jsou nepouzitelne. Vite, jak se ve windowsim shellu bezne pise sleep? Pingnete si IP s timeoutem, po ktery chcete cekat :-D http://malektips.com/dos0017.html

1. Na command line sleep snad nepotřebujete, to je věc skriptování.
2. Ve Windows můžete skriptovat v cmd.exe, VBS, PowerShellu, nebo čemkoliv jiném (klidně Perl, jestli je to váš šálek kávy). Osobně bych doporučil PowerShell, protože umí víc než například bash na UNIXech, a má daleko lepší koncept.
3. V batch files máte příkaz timeout. Ve starších verzích Windows je tenhle příkaz v Resource Kit Tools, případně můžete použít choice s parametrem /t
4. Používat ping místo timeout je hnus, ale je to srovnatelné s mnoha skriptovacími technikami používanými na UNIXech.

Timeout a sleep jsou dvě různé věci. Ani se nedivím, že to autor toho návodu výše nenašel, když to dělá něco jiného, než jak se to jmenuje.

"Osobně bych doporučil PowerShell, protože umí víc než například bash na UNIXech, a má daleko lepší koncept."

Tak tohle vyhlašuji za fórek tohoto roku. Kdyby to tak bylo, asi by dnes spoustu věcí vypadalo jinak, nemyslíte? Jste ortodoxní zastánce widlí a je to k Vaší škodě. Znalosti, zdá se, máte, ale tím nekritickým až fanatickým postojem se shazujete...

+1 PowerShell je fakt na h...o

Uz jste nekdy zkousel adminovat Windows server z mobilu treba behem nakupu s rodinou, kdyz si to situace vyzada ? A nemam na mysli soucasne hype 3g smartfouny s 800 a vice pixely. Jste nekde v prdeli s GPRS, mate u sebe jen mobil a je treba rychle zasahnout. Operace se podarila, pacient zemrel. Ja si svoje UNIXove servery okociruju s jednoduchou textovou konzoli uplne v pohode. Windows reseni vyzaduje mit neustale nekoho na poradne lajne s poradnym kompem = drazsi provoz za pohotovosti.

Jasne, na zmenu blbyho konfiguraku potrebuju nejnovejsi GUI s 3D efektama.....

Bezanie bez gui myslis to, ze sa ti namiesto explorera pusti v grafike cmd ? tak to je super vymysel, prenesiem 1024x768 bodov po linke aby som si pustil hello world. A to nehovorim ze cmd je oproti unix shellu nemouzitelna vec (to je jedno ci ksh,bash atd.)

U slabých strojů bývá problémem velikost paměti a rychlost disku. Systém nabootovaný z USB disku je pak často rychlejší. Moje doporučení pro staré stroje je upgradovat paměť jak nejvýše to jde, a místo disku tam dát SSD. A najednou je ze starého šrotu stíhačka :)

Au, ntb s 1.8" diskem jsem měl, a trpěl jsem jak zvíře. SSD se samozřejmě vyplatí, závratné zrychlení uvivíte i s WinXP. Chce to mít partition zarovnanou na 4kB, ale to přece zvládnete :)

Myslim si, ze otazka znela spise: Ma cenu dat SSD do neceho, kde ten disk bude stejne draha komponenta jako cely ntb...

Pokud vám dělá problém mít levný notebook se stejně drahým diskem, můžete kvůli tomu notebook vyměnit. Levněji vyjde nacpat do notebooku pár bankovek, abyste jeho cenu zvýšil, a postupně je vytahovat, abyste si na ten pocit "mám disk stejně drahý jako ntb" mohl pomaličku zvykat :D

Tak jako proc ne, muzu do skodovky narvat podvozek z porsche, ale toho pretizeni do zatacek abych toho vyuzil nedosahnu, ani toho ze bych mel sanci urvat to nekde tak ze jen pridam plyn(zacnu delat 3 veci najednou).

Na alze vidím 32GB za 1679, 64GB za 2699. Oboje 1.8". Redukci nepotřebujete, protože tu samou redukci má i ten HDD co máte v notebooku.

Nejak jsem nepochopil, proc mam vyhazovat penize ze vylepseni HW, aby na to bezely alespon stare Widle, kdyz tam beze zmeny HW muzu mit tucnaka, ktery bezi svizne a udela tu samou praci ?
Mimochodem, meril jsem na jednom svem novem PC i5Quad@3.3GHz/8GB-DDR3@1333/HD1­TB(90MB/s) start a vypnuti (mam natocene video)
- Windows7: 56/12sec
- openSuSE_11.4/KDE4­.6: 46/12sec
Pro upresneni:
- Win7 byly hole, po instalaci updatnute a po par restartech usazene. Zadny antivir a stovky malych systray hlidacu, ktere to cele jen zdrzuji.
- Lin/KDE je naopak jen upgradovano od prvni instalace openSuSE 11.0, coz je 19.6.2008, takze 3 roky bez ciste reinstalace. Navic mi rovnou nabiha v panelu par widgetu (monitor CPU a NET), systray doplnku (Knemo, pulse) a aplikaci (Jabber, Yakuake).
Tak mi jeste chvili povidejte o rychlosti windows.
Zkusil jste nekdy kopirovat obousmerne FTP po 1gbit LAN (na serveru SW RAID5, lokalne 2 ruzne HD) a k tomu kopirovat na dva USB2 disky ?
Pod linuchem v pohode, USB je zatez, rezie jak krava, ale ftp jelo 80MB/s.
Pod Win7 jelo ftp nejvic jen 8MB/s a rozjelo se na 40MB/s jen kdyz jsem vse ostatni zastavil a nechal jet jen jedno ftp.
Nemluve o tom, ze lokalni kopirovani 300GB z NTFS disku na jiny NTFS disk jsem taky radeji delal taky pod linuxem, protoze jel rychleji o 10MB/s nez Win7, ktere se plazily jen 47MB/s. Coz je docela LOL, ze nativni OS je pomalejsi. Kdo zna NTFS cunarnu, asi se nedivi. Na stejnem stroji a stejnych HD udelam prenos 80MB/s kdyz je tam EXT. Jasne, staci si ten 1TB disk nahradit SSD a poleti to jak raketa :-P
A nemluve o tom, ze pod win7 se mi uz parkrat stalo, ze zatuhla na chvili kvuli necemu i mys .. to neznam na tucnakovi uz par roku.
Ostatne .. stejnak se neda poradne delat na desktopu, ktery ma jen jednu plochu. Takze opravdu, ale opravdu, nevidim jediny duvod pouzivat Win7 ani kdybych je dostal zadarmo ..

630 Kč za DDR3 paměť plus 50-10k Kč za nový počítač? Není lepší dát okolo 1000 Kč za DDR2 paměti, a si nechat stávající stroj?

Skládal jsem počítač na internet a vyšlo to na 2500(atom, všechno na desce, 1GB RAM, starý disk). Další tisícovka navíc už dost prodražuje cenu a s licencí windows už se dostanu na dvojnásobek.

U Atomu je trochu problém v tom, že horko těžko přehraje HD videa na youtube, natož z FS (a natož na Linuxu, kde Flash každou chvíli žere všechen CPU, a akcelerace přehrávání videa je řekněme problematická). Co pak s takovou hračkou?

To ano, ovšem pouze na Linuxu se mi pravidelně stávalo, že Flash začal žrát 100% CPU. Řešení? Shodit Flash z command line :/. Podobnou zkušenost má asi každý uživatel Linuxu.

Nevím kdo nebo co za to může. Jen konstatuji, že slabý stroj na platformě Intel Atom má dost omezené použití, a že provozování Linuxu tomu nijak nepomůže.
Ve Windows můžete prostě odstřelit proces browseru. Příslušný tab se tím prostě obnoví. Zásadní rozdíl je ale v tom, že k podobné situaci nedochází.

V Linuxu sestřelíte proces Flashe a nemusíte sestřelovat browser ;-) Krom toho pokud browser nemá oddělené procesy pro taby, tak se alespoň umí obnovit celý (třeba rekonq nebo Firefox).

Na rozdíl od MSIE, který má oddělené procesy pro taby, a navíc se umí obnovit i celý.

Tady je potřeba říci, že MS nikdy neměl problémy psát SW pro jiné platformy. MS je nejspíš dodnes největším dodavatelem SW pro Mac, svého času uvedl Interpet Explorer i Windows Media Player pro MacOS, MacOS X, Solaris, a v případě MSIE i pro HP-UX. Podobně byly i celé Windows k dispozici pro více platforem. Jenže trh si vybírá jasně: Windows na Intelu.

Muj ty smutku, tomu snad sam neveris.
Tohle je typicky priklad placeneho diskutera. Proste medialni manipulace.
Dekuji, nechci. H.

Atom s ION vam pod linuxem v pohode prehraje FullHD video pres VDPAU. Staci si na YT vybrat lepsi kvalitu, ktera uz neni ve flv ale mp4 a mit nastaveno aby se k prehrani pouzilo cokoliv jineho nez ta sracka od Adobe a umi to HW akceleraci. A nejde jen o nvidii. Jede uz i CrystalHD a snad i to od ATI/AMD.
Nejak jsem nepochopil tu problematicnost HW akcelerovaneho prehravani FullHD videa pod linuxem ? Pouzivam ji od tech dob co to jde a rozbehne to i lama. Uplne idealni zalezitost pro Atom/ION HTPC do obyvaku.
Naopak, pokud vim, tak problematicke je to prave pod Windows 7, ktere podporu HW akcelerace NEOBSAHUJI a musite doinstalovat CoreAVC kodek, ktery to umi. Nebo pouzit jako prehravac novy Media Player Classic, ktery ma v sobe taktez integrovan demuxer s vystupem na HW akceleraci. Coz ale spousta BFU netusi a zmatene resi, proc jim HD video zatezuje CPU a obcas cuka. Pripadne proc jim pod Atom s ION defakto nejede.
Je videt ze nevite a jen vymyslite bludy. Ostatne jako vzdy, kdyz neco tvrdite o linuxu. A zaroven vhodne zatajite, ze i windy maji problematicnost HW akcelerace. :-)

já raději starou plečku bez omalovánek....a následně novou , bez omalovánek, o to navíc rychlejší jako bonus !

LOL. Jednoduchá rovnice E=m*c^2 jasně říká, že energie máme na téhle planetě obrovskou spoustu. A protože lidé jsou velmi zvídavé opice, tak se k ní vždycky nějak dostaneme.

Spotřebovat dostupný kyslík spalováním ropy? Zábavná představa :). A hordy zdivočelých pobudů jsou ještě lepší. Fallout rulez! :)
Na vašem místě bych si nestavěl fotopanel, protože udělat ho přenosný a odolný je obtížné. Na přežití scénáře Fallout bych doporučil Power Monkey Explorer (panel, akumulátor a USB konektor). Zbytek výbavy tvoří PDA, karta s DB wikipedie, zlato, antibiotika, opiáty, zbraně, a znalost libovolného bojového umění.

Jaderné elektrárny jsou dobrý a spolehlivý zdroj energie, o tom žádná. Jako perspektivní technologie bych viděl ještě biopaliva vyráběná GMO (zřejmě kvasinkami) a fuzní reaktory (ty budou nejpozději do 10 let, a tento stav trvá už cca 50 let, LOL). A samozřejmě v budoucnu opustíme zemědělství. Steaky budeme levně pěstovat jako tkáňové kultury v továrnách. Zbytek vesnické populace se přesune do měst (proces dávno začal), a za branami měst najdete jen divočinu. Zelení budou mít určitě orgáč z medvědů, vlků a další havěti co se "na venkově" namnoží :)

No ne, vy víte něco o historii téhle planety, to je příjemné překvapení. Mojí oblíbenou kapitolou je oxygen crisis (aka GOE), kdy ty zelené potvory vyhubily naprostou většinu života na Zemi vypouštěním (tehdy-)jedovatého kyslíku do prostředí, a navíc podle všeho spustily dobu ledovou.

Uhlík není na Zemi uložený zdaleka jen v ropě a uhlí. Přehlížíte takové "drobnosti" jako Alpy tvořené vápencem. Uhličitany jsou všude kolem, mimochodem včetně betonu. Velikou spoustu uhlíku najdete pochopitelně ve všem živém - a že se toho po planetě válí celé hromady :). Navíc ty zelené potvory milují CO2, což vede k autoregulační schopnosti celého systému. Výkyvy v atmosferické koncentraci CO2 jsou běžná věc, není třeba se toho bát. Pro ilustraci dnes jsme na nějakých 0.039% CO2 ve vzduchu. Kdyby rostliny mluvily, jistě by nám to popisovaly jako kritický nedostatek CO2 :)

A nemyslíte, že toho CO2 už bylo v minulosti ve vzduchu daleko víc než těch 0.039%? Závislost teploty na CO2 není nijak jednoduchá. Podle všeho se hladina CO2 mění v závislosti na teplotě, nikoliv naopak.

Klimatické změny úplně všude, to je sázka na jistotu. Klima se trvale mění. Před deseti tisíci lety byste na místě vašeho domu našel buď ledovec nebo tundru. V době tzv. středověkého klimatického optima (cca 950-1250) se na území dnešní ČR pěstovaly teplomilné fíky. V době Little Ice Age (cca 1550-1850) běžně zamrzaly velké řeky a kanály, a roku 1658 dokonce Švédové překročili s armádou zamrzlou úžinu Storebaelt, aby napadli Dánsko. Před 8000 lety byla Sahara na cca 2000 let zelená jako Skotsko. Kupodivu nic z toho nesouviselo s lidskou činností. Klima se odjakživa mění i bez nás. Zeleným se samozřejmě tahle fakta moc nehodí do krámu, protože jim kazí všechny ty krásně jednoduché poučky.

Dnešní pokusy o biopaliva jsou příšernost. Ale s GMO kvasinkami by to mohlo být jiné. Vyjede stroj (samozřejmě bez řidiče), sklidí 25-40 tun manioku na hektar, ten se nadrtí, a kvasinky z něj (z cukru a celuozy) vyrobí líh a butanol s účinností, o které si klasické kvasinky mohou nechat zdát. Do bioreaktoru můžete přihodit i recyklovaný papír, textil, zbytky jídla, a dost možná nějakou odpadní vodu.

Vy ani já sice asi nemáme sto let času, ale přesto bych výzkum fůzních elektráren viděl jako velmi důležitý. Výsledek se může dostavit i výrazně rychleji, a navíc je to pro lidstvo investice do budoucnosti. Technicky jsme realizaci velmi blízko.

Pokud jsem si všimnul, tak s tepeportací jsme zatím moc nepokročili. Naopak jadernou fúzi umíme rozjet jak ve formě vodíkové bomby, tak v experimentálních zařízeních. Problémem je energetická návratnost, udržení reakce po delší dobu, a materiály které při reakci nezdegradují. Ty samé problémy lidstvo řeší v různých variacích už od doby bronzové :)

Jak jsem psal, podobné problémy řešíme minimálně od doby bronzové. Jak dosáhnout dost té drasticky vysoké teploty potřebné k tavení železa? Co materiály které jsou k tomu potřeba? Co když se celá věc rozbije a způsobí škodu? Každý takový problém můžeme buď řešit, nebo jít lovit mamuty. Osobně jsem pro řešení těch technických problémů.

Jenže před zvládnutím technologie výroby železa to byl technologický problém srovnatelný s jadernou energetikou nebo fúzními reaktory. BTW dřevěné uhlí asi stačit nebude. Nejspíš budete potřebovat měch z kozích kožek, vybavený záklopkami. To je technika, co? Což teprve když chcete ze železa vyrobit ocel, a z té kolečko o průměru 5mm se stovkou pravidelně rozmístěných zoubků, a ložisko na které to kolečko uchytíte. Dnes takovou věc umí vyrobit v Severní Koreji. Ještě před pár generacemi byly takové materiály a způsoby jejich opracování naprosto nemyslytelné. Extrapolace vývoje (který je mimochodem exponenciální) pak jasně říká, že časem zvládneme i využití jaderné fúze.

Z dnešního hlediska relativne snadno zvladnutelne. Při pohledu zpátky je většina věcí jednoduchá.

Jak byste si predstavoval vyrobu energie na zaklade teto rovnice?
Ono je fajn ze energie je rovna hmotnosti * rychlost^2, ale jak to vyuzijete k vyrobe energie?
I kdyz je pravda, ze kdyby jste to vedel a dokazal uvest do praxe, tak se nebudete nejspis zabyvat diskuzema na rootu, ale budete resit kam se schovat pred tim najezdem zenskejch a kam vrazit prachy kteryma si uz zapalujete i v krbu..

Ta rovnice říká, že energie je dostatek. Nic více a nic méně.

Nájezdy žen a zapalování krbu prachama jsou zábavné (řekl bych teenagerské) představy o bohatství. Praxe je dost jiná.

Bohuzel se k te energii neumime dostat..

Bylo to hodne nadnesene, souhlasim. Myslenka byla takova, ze pokud dokazete teto rovnice vyuzit, tak vas ceka nobelovka a neuveritelny balik penez.

V kapitalismu bude energie vždycky dostatek, jen se bude měnit její cena. A to je právě ten problém, už poměrně dlouho se ta cena prudce zvyšuje a zastavení toho růstu je v nedohlednu.