Blizzard prý uvolní port jedné ze svých her na Ubuntu

a niekto nemusi pisat makra ale jednoducho klikne a pouzije tak predpripravene makro

tak to muselo byt velmi matne, autocad rychle cez konzoli jedine tak zadavat suradnice a rozmery , no stale je to len jedna suciastka , kombinacia viacerych uz asi konzola by bola dost nepouzitelna , maximalne sa pouziva na zadavanie presnuch hodnot tym to tak hasne dalsie veci ako sposob opracovania alebo uhol nakresu a vyrezu ...ufff

mys moze byt aj rychlejsia , stacilo by ju pouzivat nie sa na nu len divat (a ze kto sa pozera na realitu ako hratku tienov v jaskyni ?) mys je intuitivnejsia a rychlejsia a zaroven presnejsia pre ludsky odhad (kam oko zamieri tyka zamieri s nim takze synchronizacia oko ruka je lepsia cez mys)

ako priklad uvadzam hranie FPS hier na gamepadoch alebo Strategii na gamepadoch prip len na klavesnici, skuste tou klavesnicou skrolovat neaku velku plochu v strategii , je rychlejsie a ergonomickejsie jednoducho kliknut a potiahnut smerom ktory potrebujete

(dziiizs krajst , dalsi "linuxak" co hovori o realite ale nevidel/necital ju ani v man page ?)

co sa tyka 1% pokial viem tema je o hernych studiach (konkretne blizzard) a teda hernom trhu

tu zas poukazem na pocet hier ktore sa vyvyjali len a iba pre linux, boli dokoncene a boli aj uspesne ? tak isto poukazujem aj na stav tych studii ktore danu hru vytvorilo ( je dane studio pred krachom alebo uz skrachovalo ? alebo to bol neaky nadsenec a za 2 mesiace sa na to vykaslal ?)

Uhranutý puberťáci ? A ty jsi co ? Zakomplexovanej dospělák ? :D

Jaký nelegální kodek si instalují?

Jaké knihovny jsou zkopírované do Wine?

Který NOCD crack je nelegální?

pardon som to zle napisal

samozrejme ze podporoval a tlacil na vyvoj aplikacii pre jeho system, ale spoliehal sa na vyvojarov tretich stran , ak by sa nespoliehal tak vsetky aplikacie by tvoril sam google
dokonca myslim ze zo zaciatku vyvojarov aj podplacal , kedy zaplatil vyvojarom x tisic dolarov ak ich aplikacia splnila neake podmienky napr . tisic stiahnuti
tlacil tam vyvojarov spodom aj vrchom, aj tutorialy pisal a reklamu tiez tomu robil
(co nevravim ze je zle , ale nemozete potom chciet aby taka firma ked tolko do toho investovala ze to prenecha bande hipikov z komunity)

preto je teraz andorid uzavrety pretoze ma v tom nehorazne peniaze, a nechce aby mu to niekto rozforkoval na cimprcampr, a tym vyplasil vyvojarov

a mysli si co chces ale jednoducho ani jedna firma co je v Linux Faundation to nerobi pre Linusove modrozelene (ci ake ma) oci alebo ze zachrani planetu super lacnym systemom

podporuju to preto ze mozu linusovi nahadzat kde aky bordel oni potrebuju rozchodit aby dal do kernelu , preto je tam virtualny server a ine priblblosti ktore pre bezneho uzivatela na desktope su nepodstatne (to bol zamer vytvorenia linux kernelu , pre bezneho desktop uzivatela)

ak by linus neupratoval , kolko by mal linux kernel za 50 rokov ? 10 giga ?
je to skratka cisty biznis, to ze je na linuxe nalepka free a pre dobro naroda a za slobodu a mier , je len velke plus (no nie hlavne plus) pre firmy ktore na tom stavaju imidz

ten programovaci jazyk myslis lahky z HW poziadaviek alebo lahky ze sa ho nauci aj podpriemerny programator ? s tymi HW poziadavkami vsak nesuhlasim
inac java sa tiez rozsirila pretoze to SUN tlacil vrchom spodom na vyvojarov a ze to SUNu zlomilo vaz (spolu s dalsimi projektami , >_> looking at you solaris and sparc)

google linux kernel neocesal a neodladil , odladil iba tu svoju cast ktoru potrebuje (ci uz android alebo chrome os) to ze par google programatorov vo volnom case niecim prispeje este neznamena ze to google podporuje
a co sa tyka androidu ten ocesal a vyladil az po kolkych rokoch (az od verzie 2.3 sa povazuje android za pouzitelny , a az tento 4.0 za vyladeny) a to len preto ze ho uzavrel a spravuje jeho vyvoj tak ako sa na firmu ktora chce nieco dosiahnut patri

preto je teraz andorid uzavrety pretoze ma v tom nehorazne peniaze, a nechce aby mu to niekto rozforkoval na cimprcampr, a tym vyplasil vyvojarov

Android není uzavřený, je licencovaný pod Apache License, stejně jako naprostá většina SDK. Uzavřené je SDK stažené z android.com, protože obsahuje některé komerční části vyvinuté výrobci telefonů (specifické pro Android na těch telefonech), ale pokud chcete Android forknout, tak vás to vůbec netrápí, velmi jednoduše si vytvoříte vlastní včetně SDK.

podporuju to preto ze mozu linusovi nahadzat kde aky bordel oni potrebuju rozchodit aby dal do kernelu , preto je tam virtualny server a ine priblblosti ktore pre bezneho uzivatela na desktope su nepodstatne (to bol zamer vytvorenia linux kernelu , pre bezneho desktop uzivatela)

Bordel se do Linuxu nedostane, veškerý kód pro zařazení musí projít dost složitým procesem schvalování.

KVM (linuxový virtuální server) nemá s Googlem nic společného. Virtuální server je i ve stolních Windows 7.

Jinak distribucím nic nebrání tyhle věci vypnout a nemít je tam, pokud by je nechtěly. Ale tohle nikdo neřeší, protože pokud KVM máte, ale nepoužíváte, zabírá akorát kolem 650 KiB (ano, méně než jeden megabajt) na disku.

google linux kernel neocesal a neodladil , odladil iba tu svoju cast ktoru potrebuje

Ale přesně takhle vývoj Linuxu funguje ;)

Proč si myslíte, že mám na diskusi nějaký ekonomický zájem? Není to tak že mám prostě na některé věci jiný názor než vy?

Na diskusi určitě ne. Na prosperitě jedné firmy určitě ano.

Na platformě Microsoftu mám asi stejný finanční zájem, jako účetní běžící svůj SW na Windows :D. Pokud někdo nabídne lepší ekosystém, je racionální na něj přejít. Jenže když se podíváte na technickou kvalitu, podporu HW, nabídku SW produktů, vývojové nástroje, dokumentaci a produktivitu, moc alternativ k MS platformě neexistuje.

Je pěkné že to tak vidíte, ale mě je spíš líto těch konkurentů :)

Technickou kvalitou myslíte možnost vzdáleně jej ovládat bez vědomí uživatele? :-)

To jistě také :), ale spíš jsem měl na mysli architekturu kernelu, správu paměti, prioritizaci I/O, vyspělý FS, široké a dobře dokumentované API atd.

Pokud se na technologie Windows podíváte z větší blízkosti, tedy ne jen skrz Windows Explorer a desktop, tak ty kvality nejspíš uvidíte také. A asi také uvidíte, že Linux rozhodně není žádným technickým zázrakem, ba spíš naopak. Technicky nejlepším unixem je zřejmě Solaris, některé zajímavé vlastnosti má i HP-UX.

Negativní zkušenosti můžete nasbírat u spousty produktů. Já jich nasbíral celkem dost u profi unixů i Linuxu (a mimochodem i u Oraclu). Windows samozřejmě také někdy zlobí (zvlášť díky HW a driverům), některé vlastnosti by určitě mohly být lepší, ale situaci považuji za výrazně lepší než u konkurence.

Navíc jsou ty údajné problémy s Windows často důsledkem neznalosti. Vždycky mě překvapuje, když se někdo neumí naučit celkem jednoduchou administraci Windows, ale zato se memoruje jména a syntaxi stovek příkazů, umí skriptovat v bashi, píše regexpy, zná jména a umístění hromady konfiguráků atd. Částečně to asi bude podobné jako u MS Office. Jednoduché GUI dává některým lidem pocit, že tomu celému vlastně jaksi automaticky rozumí, natož když pracují s počítači "odjakživa". Jenže bez znalosti fungování té věci pod kapotou se v ní fakt nemůžete úspěšně rýpat (což se třeba od pokročilého Windows admina očekává).

Zkuste si ten link přečíst ještě jednou. Systémové adresáře se prohledávají *před* CWD u XP SP2 a vyšších, a ještě před tím se prohledává KnownDLLs (který u mě obsahuje link na %SystemRoot%\sys­tem32).

Z toho linku jste si vybral pěkný kousek, samozřejmě bez přečtení toho zbytku. Vlastní ws2_32.dll vůbec nezavedete (stejně jako cokoliv se jménem z adresáře %systemroot%\win­dows32), protože je to v KnownDLLs. A samozřejmě pokud natahujete knihovnu bez určení adresáře, a modul toho samého jména je už paměti, tak se tento použije. Na Linuxu doufám nenatahujete kopii každé knihovny znovu pro každou aplikaci :)

Aha, máte pravdu, prázdný LD_LIBRARY_PATH se asi ignoruje. Prázdný token se ale neignoruje.
http://stick.gk2.sk/2009/10/wrong-usage-of-ld_library_path/
BTW pro Windows najdete i doporučení, jak knihovny bezpečně natahovat.
http://support.microsoft.com/kb/2389418

Ano, aplikace na všech platformách mají doporučená místa k ukládání konfigurace, a ukládají si je kde chtějí.

Roaming profil neimplementujete bez rozdělení konfigurace/souborů na část specifickou pro stroj a specifickou pro uživatele. Například 250MB cache browseru nemá smysl tahat na síť, může zůstat jen na lokálním stroji. BTW dělit uložené soubory na lokální a roamovatelné se od jisté verze naučili už i autoři Firefoxu :D

Pletete si konfigurační hodnoty (connection string k DB, rozmístění toolbarů v aplikaci), uložené a dočasné soubory (save games, cache browseru).

GP se vám nelíbí? Mě se zase moc nelíbí dávkové soubory. Uživatel má notebook a přihlásí se mimo síť, pak se připojí k síti, a dávka neproběhne. Naopak GP se aplikuje i při pozdějším připojení k síti. Na unixech ale o ničem srovnatelně silném a jednoduchém nevím.

Regexpy mají poměrně zásadní nevýhody: těžko se učí, a jsou velmi špatně čitelné. Samozřejmě na unixech musíte administrovat tak, že spouštíte utility, parsujete textové výstupy a krmíte tím jiné utility. Autoři Windows to umí udělat komfortněji. Vyjma GUI můžete použít objekty místo parsování: Get-Service | Where-Object {$_.status -eq "running"}. Snadno se to učí a dobře se to čte.

BTW ty poznámky o nedostatcích Linuxu jste přešel dost tiše. Mohl jste napsat alespoň "máte pravdu" ;). Například absence API pro deamony fakt nepotěší. Máte jen hromadú skriptů, samozřejmě na každém unixu jinou, a žádné API. Příkladů jsem uváděl více.

Máte špatně konfigurační hodnotu v Registry i po instalaci XP SP2? Nepotěší, ale o příčině se mohou pouze dohadovat. KnownDLLs u mě %SystemRoot%\sys­tem32 obsahují, u vás opět ne. Máte asi někde něco zatraceně špatně.

Jo, změnit knihovnu za běhu a natáhnout novému procesu jinou verzi, to je terno. Například když máte aplikaci jedoucí v deseti procesech, pak nastartujete jedenáctý, a ten zrovna začne používat tu novou knihovnu, která má nějaké změny (třeba jiný formát dat ve shared memory nebo na disku). Tomu se říká "when shit hits the fan", z čehož asi pochází české "a je vymalováno". Podobně "skvělá" je možnost aktualizace běžících aplikací. Jednak to přináší úplně stejný problém, a potom ty běžící aplikace nejsou ve skutečnosti záplatované. Ovšem proč se starat tyhle drobnosti, když máte Linux třeba race conditions při přístupu k FS. Jeden thread vytvoří soubor a dostane handle, jiný thread do něj zkusí pomocí toho handlu zapsat, a on prý soubor neexistuje. U Postfixu to tuším řešili přepsáním kódu... aplikace(!). Bohužel podobných problémů se vyskytuje více než dost.
http://lkml.indiana.edu/hypermail/linux/kernel/0107.3/0358.html
https://bugzilla.kernel.org/show_bug.cgi?id=13232
http://www.root.cz/zpravicky/ext4-pomohlo-odhalit-spatne-napsane-aplikace/
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/317781

LD_LIBRARY_PATH může nastavit běžný uživatel, a security by obscurity mi jako moc dobrá ochrana nepřipadá :)

Pokud jste se střetl jen s aplikacemi z repozitáře distra, tak můžete mít pravdu. Pokud jste provozoval komerční aplikace, tak jste si musel všimmout, že většinou mají konfiguraci na jiných než doporučených místech. Oracle a Lotus Domino jsou pěknými příklady. A vyjma konfigurace ve vlastních adresářích (mnohdy divoce roztroušené) tam bývají i rc skripty, věci typu /etc/oracle apod., takže o centralizaci konfigurace nemůže být řeč. Podotýkám, že Oracle je portovaný z unixů na Windows, a nikoliv naopak. Na Windows nás všechny velmi "těší" například jeho dodnes přetrvávající problémy s cestami obsahujícími mezeru. Konfigurace potroušená po disku je proti tomu nuda.

Roaming profily na Windows samozřejmě nekopírují celý %HOME%. K čemu myslíte, že je v profilu podadresář Local Settings (od Visty výše AppData\Local a AppData\LocalLow)?

OOM Killer můžete vypnout, a můžete vypnout i overcommit. Bohužel vám pak velmi brzo dojde paměť. Za to může mimo jiné typická konstrukce fork()/exec(), která spoustu paměti označuje jako CoW.
Useradd je skript, nikoliv API. To přesně kritizuji. Totéž třeba u té změny IP adresy, přidání nebo zastavení daemona atd. Ale zase si vždycky můžete forknout příslušnou utilitu (yuk), abyste trochu podráždil ten OOM Killer :)
GDI je skvělé díky tomu, že je v základní instalaci Windows, a umí kreslit stejně po obrazovce, plotteru, tiskárně i Remote Desktopu (to umí tuším od NT4). Metafiles, vysoká rychlost, malý overhead. X11 je proti tomu pravěk. BTW opakované volání CreateWindowEx() u mě vrací po 10k objektech tuším ERROR_NOT_ENO­UGH_MEMORY, protože těch 10k je limit nastavený v registry (GDIProcessHan­dleQuota). Že vy to máte zase nastavené špatně? :)
Myslím že na to, aby člověk hodnotil negativně kernel s Big Kernel Lockem, OOM Killerem a řadou dalších "vychytávek", není třeba nijak milovat jiné systémy. Stačí se na ně jen podrobněji podívat. I Solaris je proti tomu zlatý.

Ano, programy používající XML konfiguraci ji musí ukládat na FS. Tu posedlost XML moc nechápu. Máme silnější CPU a víc paměti, tak místo úsporných a rychlých binárek začneme požívat XML, ať je to trochu pomalejší a žere to víc paměti :/

Komfortně vs omezeně: počítače mohou dělat spoustu věcí. Teoreticky může file manager na stisk pravého tlačítka myši přehrát soubor jako 44.1k PCM na zvukové kartě. Ale proč? Snadno by měly jít dělat ty věci, které se dělají často.
Vytvoření wrapperu pro každou činnost úplně stejně vyžadují unixové utility. Rozdíl je v tom, že se objekty se daleko lépe pracuje. Pracujete s abstrakcí bližší cíli své práce, nikoliv s parsováním textu. Můžete vytvořit nebo vybrat objekt uživatele, servisu apod. A zkuste s unixovými utilitami tohle:
$excel = new-object -comobject Excel.Application
$workbooks = $excel.Workbo­oks.Add()
$worksheets = $workbooks.wor­ksheets
$worksheet = $worksheets.Item(1)
$worksheet.Name = "Name of Worksheet"
$worksheet.Ce­lls.Item(3,3) = "Title of Excel Document"
$worksheet.Ce­lls.Item(3,3)­.Font.Bold = $True
$worksheet.Ce­lls.Item(4,3) = "This is really cool"
$worksheets.Prin­tOut
$workbooks.Sa­veAs("c:\dir\au­tomate.xlsx")
$excel.quit()

Get-Window -Title "Untitled - Notepad" | Set-WindowState -Minimize

Get-Service | Where-Object {$_.status -eq "running"}

Jednoduše zapamatovatelné, velmi silné. Unixové shelly byly samozřejmě skvělé před třiceti lety, všechna čest, ale snažit se je narazit na dnešní zvyky uživatelů a dnešní způsob používání počítačů je marné. PowerShell je skvělý dnes.

Chcete jen řádky neobsahující dané znaky? Vezmete string se znaky, převedete na pole, pro každý znak použijete Select-String nebo filtrování pomocí Get-Content <file> | Where-Object {$_ -notmatch ...}. Samozřejmě můžete použít i regexp, tenhle je zrovna triviální, a ušetříte si ten cyklus. Já bych osobně použil VBA bez regexpů, protože ho velmi často používám v Excelu. Drsnější jedinci by jistě použili dávku s cyklem for %i in (z n a k y). Praktickou demonstraci všech možností zvládnete po téhle nápovědě jistě sám, já jdu spát. BTW běžnému uživateli bych doporučil si legálně koupit film i s titulky :)

Ad SafeDllSearchMode: pokud u vás hodnota chybí, je to u XP SP2 a výše považováno za 1. Pokud tam máte nulu, může to být nastavené například v Group Policy. Víc o tom nevím - je to nakonec váš systém, ne můj :)

Ad KnownDLLs: já tam mám položky DllDirectory s hodnotou %SystemRoot%\sys­tem32 a DllDirectory32 s hodnotou %SystemRoot%\sys­wow64. Mimo to je tam také WS2_32.

Ad záměna knihovny za běhu: ano, fork() zachovává knihovny. Ale samozřejmě jen ty natažené před forkem, a jen pokud použijete fork.
Ad aktualizace běžících aplikací: ano, otevřené handles dále referují stávající soubory. Jenže 1. běžící proces není záplatovaný, 2. aktualizace neotevřeného souboru (třeba resources, nenataženého pluginu apod) může vést k průšvihu, 3. nově spuštěné procesy mohou mít problémy s komunikací s těmi starými. Jinými slovy do restartu aplikace to může a nemusí fungovat.

Ad problémy MTA: jak jsem linkoval, problémy jsou v rozbitých FS. Atomické operace nejsou atomické a vyskytují se různé race conditions. Je to smutné, ale je to tak. S rozbíjením BKL lze čekat, že vyplave řada dalších podobných problémů.

Ad OOM Killer: ono bohatě stačí, když si například DB server alokuje příliš paměti. Malloc() mu ji s klidem slíbí (overcommit), a když do ní proces zkusí zapsat, paměti se najednou nedostává. Situace se řeší odstřelením vylosovaného procesu. To vede jednak ke snížení spolehlivosti systému, a potom také k chybějící obsluze low memory condition v aplikacích (proč něco takového psát, když stejně zasáhne OOM Killer). Solaris ani Windows neslibují paměť kterou nemají, a když paměť dojde, nechají prostě alokaci selhat (obsluha stavu je pak v režii aplikace). AIX sice overcommit provádí, ale má alespoň SIGDANGER, kterým aplikacím umožní na low memory patřičně reagovat, než začne házet SIGKILL.
BTW Andries Brouwer napsal krásnou paralelu k OOM Killeru s letadly.
http://lwn.net/Articles/104179/

Fork()/exec() je samozřejmě velký problém. Mějme server s velkou alokací paměti. Teď potřebujete spustit nějaký externí program, třeba utilitu. Může to být proto, že pro danou akci neexistuje API (o čemž už jsem také psal). Provedete fork(), a tím duplikaci procesu. Veškeré jeho stránky jsou označené jako CoW, takže systém musí počítat s možností jejich modifikace. Následný exec() sice tu CoW alokaci efektivně zruší, ale to už je pozdě. Když váš server alokuje 4GB RAM a potřebuje spustit utilitu, musí mít systém další 4GB volné paměti. Tenhle mechanismus je primární důvod, proč Linux provádí memory overcommit, a proč pak potřebuje OOM Killer. Další ingrediencí je absence threadingu (použitelného - hackované LinuxThreads byly ostudou Linuxu) až do jádra 2.6, díky které se na Linuxu ve velkém forkovalo. A pak je tu absence mechamismu obdobného SIGDANGER na AIXu. Je to jedno s druhým, a tohle se autorům prostě silně nepovedlo. Kdyby na začátku provedli slušný design OS, nemuseli by pak zavádět spoustu špinavých polofunkčních hacků.
BTW NPTL jsou sice o řád lepší než LinuxThreads, ale mají své mouchy. Opět to souvisí se špatným počítačním designem kernelu. Samozřejmě by také synchronizační objekty mohly být rychlejší, ale nemůžete od Linuxu čekat výkon Windows :)
http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/linux-thread-problems.html

Dalšími podobnými problémy jsou BKL (po letech úsilí úspěšně rozbitý na subsystem locky, což je pořád málo), prioritizace interruptů atd. Extreme Programming je sice zajímavá technika, ale u projektu typu OS to vede k nutnosti rozsáhlého přepisování.

Ad useradd: V Single UNIX Specification Version 4 není o useradd žádná zmínka. Nemusel bych useradd jako syscall, spíš jako funkci nějaké knihovny pro správu systému.

Ad shell:
- Streaming médií se snažíme na Windows řešit tak, aby to mohl použít i uživatel. Takže stačí otevřít Windows Media Player, označit soubor, a říci kam se má streamovat na kompatibilní zařízení. Nebo můžete použít například Virtual Audio Cable. Ten vytvoří virtuální zvukovou kartu, tu nastavíte buď pro danou aplikaci nebo celý systém, a připojíte klienty.
Device files a pipes jsou samozřejmě zajímavá věc. Jak ale zajistíte, že nezačnete číst data zvukovky třeba s offsetem jeden byte od hranice samplu? To by encoder neměl rád :). Jak encoder zjistí z pipy bitrate a bitovou hloubku streamu? Co když se bitrate nebo sample rate změní? Co když jde o formát vícekanálový typu Dolby Digital nebo DTS? Podle mě to nebude tak jednoduché, pokud to má opravdu fungovat.

Unixové shelly jsou samozřejmě i dnes dobrým nástrojem pro úkoly, které uživatelé a admini běžně řešili před těmi těmi třiceti lety. Dnes ale počítače používáme jinak, a liší se i cílová skupina zákazníků.

troll text inside > tak pekne chlapci , ciciny ste si pomerali , sneh ste uz svojim mocom popisali , uz ste aj skusali kto dalej docura, tak by ste to mohli aj ukoncit , nemyslite ? < / troll inside

ale teraz vazne , vasa diskusia o porovnavani bezpecnosti a pouzitelnosti oboch systemov vypada byt zaujmava (pre technicky zdatneho administratora ci hackera, no ovela menej uz pre bezneho uzivatela) skuste ju previest na forum a tam pokracovat ak sa vam este chce

hlavna otazka vsak ostava a tema diskusie pod clankom je ci je na linuxe neaka hra podobna kvalite a rozmerom, poctu uzivatelov alebo velkosti virtualneho sveta, tomu od blizzardu > WOW <, a ziadne konverzie z windows ci inych platforiem , priamo vyvyjana pod linuxom a vyvyjana pre linux

osobne som nenasiel ZIADNU, takze to tiez hovori o kvalite systemu , kolko kvalitnych a pouzitelnych aplikacii pre dany OS existuje , to ze sa niekto s tym hra na servri , a robi upravuje to pre neaky nenasitny mobilny OS je sice fajn ale pouzitelnost je trocha mimo

bte -to ze na mobil potrebujem 512MB ram aby bezal plynulo a 1Ghz procesor je aj pre tak stary os ako je windows XP dost, nie to pre 20 !!!DVADSAT ROKOV VYVYJANY OS !!!"

takze este raz , HRY , mate neake ?

ano trocha ustrelne, no ak citate pozorne (vco dufam pretoze ak citate manualy tak flakajuco/speedread ako citate komentare...)
pisem tam ze nie len kvalitny OS, v tomto pripade iba kvalitny kernel, zvysok os v GNU/linux je neak... mimo

ale HLAVNE kvalitne aplikacie, clanok hovori "... Blizzard prý uvolní port jedné ze svých her na Ubuntu ..." takze sa jedna o hry a nie o to ktory OS je bezpecnejsi ci kvalitne spraveny a zaciatok tejto diskusie bol o... ze by blizzarde a hrach na linux ?!?

ono paci sa mi vasa diskusia (ci skor porovnavanie si ...) s loal je to zaujmave technicke a vydno ze sa obaja vyznate ale
za 1, uz to nie je citatelne
za 2, tazsie sa to hlada v historii clankov aby sa dali vase porovnavania citat
za 3, je diskusia o HRACH a preco je ich na linuxe tych kvalitnych tak malo (aby som to spresnil pisal som o hrach robenych na linuxe a pre linux , takze porty z inych platforiem sa nepocitaju)

=============­========================­========================­==
kedze pocitam ze to aj tak nikto nebude citat , teda urcite nie cele

prejdite na forum nech sa ta vasa diskusia lepsie cita a vyhladava

Ad vyznam DllDirectory v KnownDLLs: všechny knihovny v daném adresáři se zavádějí jako Known DLLs, tedy na prvním místě search order.

Ve Windows se aktualizace aplikací řeší tak, že pokud je nějaký soubor používán, buď vyzvete uživatele k ukončení aplikace, nebo k restartu po dokončení instalace. Jen tak je možné předejít problémům. Aktualizace terminálových serverů se provádí během plánované odstávky. Je totiž lepší restartovat, než nechat uživatele po aktualizaci bez restartu s potenciálně nefunkční aplikací.

Streaming médií z PowerShellu bych asi řešil pomocí nějakého objektu Windows Media Playeru, na MSDN je obsáhlá dokumentace. Ve Windows většina aplikací vystavuje nějaké COM nebo .NET API, s výjimkou domácích projektů a Notepadu :). Je také možné použít UPnP/DLNA API. Tam to chce vytvořit objekt MediaRenderer (ten budete muset najít pomocí UPnP.UPnPDevi­ceFinder), nastavit mu zdroj pomocí SetSourceFrom*() a zavolat PlayAtSpeedAsync(). Asi by z toho byl pěkně divoký one-liner :). Výhodou je, že to funguje i na XBOXu, televizi apod. Dá se tak provádět i správa toho zařízení. Ale upřímně: než bych se s tím patlal, raději spustím ten WMP a vyberu Play To z GUI :)

Zkontrolovat Facebook ze shellu můžete, ale je to trochu přes ruku. A podobné je to se spoustou akcí, které se dnes s počítači provádí celkem běžně.

Touché, dostal jste mě :). Takže jsou to na prvním místě KnownDLLs (ve kterých NENÍ %windir%\system32), na druhém místě app startup dir, a teprve na třetím místě %windir%\system32.

Ano, plaintextovou dokumentaci můžete komentovat, a editovat ji pak v konfiguráku. Podobně konfigurační DB můžete "komentovat" pomocí GUI. Ve srovnání s GUI je editace konfiguráku mírně řečeno přes ruku. Svět se od dob tradičních unixů změnil - nový účet v KMailu ani Thunderbirdu nezakládáte editací konfiguráku. Navíc spousta té textové konfigurace komentovaná prostě není. A k tomu má textová konfigurace ve srovnání s binární příšerný výkon. Pro čtení to máte O(n) vs O(log n), v případě zápisu musíte soubor kompletně přepsat, vyvstávají concurrency issues...

Komentáře si samozřejmě můžete vložit i do Registry. Stačí si vytvořit položky s description. Například já si můžu v KnownDLLs udělat položku "#DllDirectory" s hodnotou "Library base path - files in the directory are NOT automatically included on the list of KnownDLLs" :). Jak jsem ale psal, spousta konfigurace není dokumentovaná ani v textové konfiguraci.

Opravdu jste si jistý, že například konfiguráky OpenOffice jsou menší než 200kB? Nemám teď po ruce žádnou instalaci, ale mám o tom značné pochybnosti. Ty desítky tisíc konfirugačních hodnot mají svou velikost, zvlášť v XML formátu. Nakonec dlouhé načítání konfigurace je jedním z důvodů pomalého startu OOo. A ty XML soubory jsou bez komentářů, pokud si správně vzpomínám. Komentáře by totiž nafoukly jejich velikost na několikanásobek.

Osobně nevím o aplikaci, která by položky v Registry enumerovala tímto způsobem. Pokud taková existuje, můžete umístit popis do nadřazené větve. Podobně můžete komenráře nazvat třeba value_comment místo #value. Nicméně v praxi je nejlepší použít prostě GUI. To se dá napsat velmi snadno.

Výkon je ještě důležitější, když nejde jen o stavení aplikace, ale také o registraci komponent. BTW export Registry na typickém systému má desítky až stovky MB textu. BTW2 Registry mají i další výhody: řádově rychlejší zápis, transakční zpracování, automatický backup s možností návratu k minulému funkčnímu stavu (Last Known Good Configuration), možnost současného read/write přístupu z více vláken/aplikací, možnost rychle načítat hodnoty podle potřeby.

No, Windows má víceméně kvalitně navržený kernel, i když by to mohlo být lepší. Implementace ale už často pokulhává, teď se to s nedávnou (znovu)portací NT jádra na ARM snad alespoň o něco zlepší.

Od Visty je konečně správa paměti skoro na úrovni Linuxu a půlka paměti už neleží jen ladem. Stále ale chybí overcommit, ale MS na tom prý pracuje (kupodivu hlavně pro servery, kde overcommit nemá takový smysl).

NTFS je docela vyspělý systém, i když za ty roky se do něj nabalilo spousta balastu. Bohužel mnoho jeho skvělých vlastností úplně zabíjí Win32 API, některá nesmyslná omezení (proč nejdou symlinky na soubory?), dost špatné alokační strategie (hrozně fragmentuje) a slabší odolnost proti chybám.

V čem konkrétně spočívají ty implementační nedostatky?

Windows doufám nikdy nebudou mít správu paměti na úrovni Linuxu. Overcommit se do Windows také nedostane, protože když systém lže o alokaci paměti, a pak se na tu lež přijde (slíbená paměť prostě není), tak je potřeba nějaký proces vylosovat a odstřelit. Do toho se MS "kupodivu" nechce. Místo toho MS používá Dynamic Memory. Když virtuální stroj potřebuje více paměti, řekne si o ni. Když ji nedostane, alokační volání aplikace selže, a aplikace se podle toho může zařídit (zmenšit buffery apod).

NTFS je o dost vyspělejší, než FS na unixech (šifrování, komprese, BitLocker, prioritizace a rezervace přenosového pásma). Proč to podle vás Win32 zabíjí? Alokační strategie mi přijde v pohodě. Samozřejmě při dostatečném zaplnění disku fragmentace roste, ale to u každého prakticky použitelného FS. Odolnost proti chybám je u NTFS naopak dobrá, protože boot sector (superblock) i všechna metadata mají dvě kopie.