Valve potvrdila Steam pro Linux, nejprve bude pro Ubuntu

Ach trvalo to len 2 roky ale sen sa mi plni.
http://trsek.blog.root.cz/2010/09/13/linux-a-hry-prave-toto-spojenie-ma-buducnost/

Zajímalo by mě, zdali pojede L4D i na svobodném ovladači. Karta výkonná je(HD 7700), rozlišení malé(1280*1024) a Ubuntu 12.04 s ní ještě neumí 3D akceleraci :D, jinak, určitě bych si to koupil, jestli bude linuxová verze, už jen kvůli toho, abych jim ukázal, že to za to stojí(portovat na linux).

Ale prdlajs. Nezavislych her pro linux je dost a je o ne i zajem. V Humble indie bundle to jedno procento zastupuje petinu prodeju a je ochotno platit dvoj az trojnasobek toho co na Windows.

Zatím co na Linuxu je Indie Bundle novinka, na Windows jde o výprodej her, které jsou k dispozici už dlouhá léta (například na Steamu). Komu se ty hry líbily, koupil si je už kdysi zvlášť. Já například zaplatil jen za World of Goo EUR 20, a podobně s pár dalšími tituly z těch bundlů. Jinými slovy situace na Windows a Linuxu je rozdílná, takže srovnání pokulhává. Navíc těžko z výprodeje indie her s cenou do dvou dolarů něco usuzovat o poptávce po áčkových titulech za 50 EUR :)

BTW drobný problém Indie Bundle je v tom, že autoři her dostávají jen minimální část ze zisku. V sekci Software "counterfeits" si můžete přečíst i o "výhodách" uvolnění zdrojáku hry.
http://en.wikipedia.org/wiki/Indie_bundle#Criticism

A to že některé hry byly starší něco mění na tom, že je o jejich linuxové verze zájem?

World of Goo za EUR 20. To byl tedy dost předražený. Cena indie her se pohybuje kolem 10 euro nebo 15 dolarů. Myslím, že jsem u nás krabicovku kupoval tak za 200 nebo 250 korun.

V posledním bundlu byly Bastion a Lone Survivor což jsou hry z minulého roku (Lone Survivor možná letošní). V předposledním byla Botanicula, která je letošní ne více než půl roku stará.

To že se jednomu producentovy asi nelíbily podmínky a asi měl problém se s HB dohodnout a že druhý si stěžuje, že pozdější bundly se prodávaly pomaleji jako první, že limbo nebylo nativní, ale zabalené v CrossOver to je drtivá kritika která naprosto deklasuje zájem o ty hry. Uvolňovat zdrojáhy není požadavkem HB. Jo někteří lidé jsou hovada. Ale samozřejmě ne každému podmínky vyhovují.

Hlavním problémem u indie her je jak je dostat do povědomí a k zákazníkovi, což steam pro win a mac eliminuje a pro linux by to mohl udělat taky. A minimálně ty hry co mají mac port by nemělo být tak těžké portovat.

Na gog.com už taky pár měsíců visí požadavek na linuxůvé verze her pokud existují. A tam se nově prodávjí indie hry bez drm jako rojlíky. Ta nepřítomnost drm je pro mě mnohem důležitější než aby byly free nebo open source.

No a že velké korporace nebudou mít AAA hry pro linux hned po tom co linuxový steam vyjde. Korporace jsou vždy konzervativní a nové koncepty nechají prověřit startupy (tady nezávislou scénou) a pokud se ověří tak startupy koupí nebo se postí do stejné myšlenky. Uvidíme časem.

Nechci teď předvídat úspěch nebo neúspěch na Linuxu, ale rozeberu trošku, co to ovlivní.

První věc je, kdy se to výrobci vyplatí: musí platit současně obě tyto podmínky:
a) dodatečný výnos (prodeje na Linuxu mínus úbytek prodejů na Windows) bude vyšší než dodatečné náklady (tj. asi hlavně náklady na portaci, nikoli náklady na celý vývoj)
b) tato investice bude nejlepší možnou (tzn. musíme započítat tzv. náklady obětované příležitosti)

Dodám, že náklady na portaci by měly právě Steam a Source engine stlačit dolů.

Zřejmě nelze hodnotit vynosnost jako prodeje na Windows * (podíl Linuxu / podíl Windows) i z dalších důvodů:
a) Ochota platit za software. Paradoxně může být u uživatelů Linuxu větší. Uvedu třeba http://www.latrine.cz/linuxaci-za-hudbu-nezaplati-ani-nahodou nebo fakt, že mnoho uživatelů Linuxu má OEM Windows a tak na licenci nic neušetří. Někdo tu uvedl Humble bundle Indie. Já zase radši nechci vědět, kolik jsem dohromady zaplatil za aplikace pro Android. (Ano, u Androidu ne všichni jsou ochotni platit, I ve srovnání s iOS. Asi to ale dost ovlivňují majitelé levnějších modelů.)
b) Konkurence: aspoň zpočátku pro Linux bude vyvíjet jen část výrobců. Budou na tomto trhu mít menší konkurenci, takže relativně (vzhledem k velikosti hráčské základny na dané platformě) větší zisk z jedné hry než na Windows. Pokud se podíl Linuxu na trhu (nebo spíš velikost Linuxové hráčské komunity) nezvětší, bude zde trvale menší konkurence. Pokud se zvětší, bude to signál pro další výrobce.
c) Podíl hráčské komunity na dané platformě - to může být největší problém Linuxu. Uvidíme.

Náklady na portaci budou nejspíš vysoké. Musíte najmout lidi, kteří píší pro Linux. Musíte najmout testery s různými distry Linuxu. A pak jsou tu náklady na support: musíte mít odborníky, kteří rozumí Linuxu. A musíte podporovat různá distra.

Linux má problém v malé uživatelské základně, které je cca 100x menší než na Windows. Ochota platit za hry by mohla s věcí zahýbat, jen pokud by na Linuxu byla *řádově* větší než na Windows. To by mě ale velmi překvapilo. Menší konkurence sice může zpočátku hrát jistou roli, ale podle mě to nespasí.

Ale hlupost. Vacsina major distribucii je postavene na debiane a aj Steam zacina na Ubuntu, takze nie je co riesit.

Takže podle vás stačí podpora jednoho distra v jedné verzi? I to může být problém například s různými drivery. Ale trochu se obávám, že podpora jednoho distra v jediné verzi nestačí.

Zajímavé, že podobně to dělá id Soft a funguje jim to ;-)

No jo, id soft udělal s Linuxem díru do světa :). John Carmack prohlásil o portu hry Rage (mimochodem psané pro OpenGL) následující: "We are not currently scheduling native linux ports. It isn't out of the question, but I don't think we will be able to justify the work."
http://current.com/technology/90807671_john-carmack-discusses-linux-version-of-rage.htm

opengl se mi sice libi, ale ty extensions to zabily.

Soucasny catalyst driver ma 231 opengl extensions. Pri psani rendereru je bohuzel dost zasadni problem zda je nejaka extension podporovana nebo ne.

OpenGL standard je podobnej J2EE - neni moc pouzitelnej bez custom rozsireni. Takhle to dopadne, kdyz se standardy navrhavaji co nejjednoduseji. Sice to pak umi naimplementovat kazdy, ale vzhledem k nekompatibilnim rozsirenim bez kterych se moc pracovat neda to standard neni.

Idsoft mel vsechno pro linux, takze ma bohaty zkusenosti kolik se toho na linuxu proda.

Počkat! Extensions pro vývoj her už nejsou potřeba. To platilo za OGL 1.1, kde jste ho s pomocí extensions narvali na úroveň 2.0. Od dvojky už se daj psát hry na úrovni cca. DX9 úplně bez extensions (žádný arb shadery). Teď už máme OGL 3.3 a 4.x (ouha, doba se změnila :), které jsou podporované na dostatečné většině moderních karet. Ty umožňují čisté cokoliv co může vývojář potřebovat... Extensions jsou VÁŽNĚ už 5 let nepotřebné pro vývoj her (i aplikací).

nevidim problem, portovania hry na ine distra pokial sa to rozchodi na ubuntu.

A portace z konzolí na windows je řádově jednodušší to jen musíte mít různé sestavy s vindows xp, vista, 7 a brzo 8 v různých verzích s různými verzemi knihoven různými service packy a záplatami a různými verzemi ovladačů. Potřebujete lidi co umí pro toho prostředí psát (gta4 a jiné sprzněné porty). Prostě velká herní firmy do toho hned nepůjdou jen až pokud jim poteče do bot.

Vysoké - v porovnání s čím? V porovnání s vývojem hry pro Windows (od nuly) asi moc ne. Tyto všechny náklady máte u Windows taky (navíc ta podpora je z velké části proporcionální k počtu koupených licencí). Podpora různých distribucí je už lepší argument, ale nejspíš taky moc nákladů nepřidá, pokud vůbec bude ta podpora oficiální. (Taky mohou říct: tady máte hru, oficiálně jede na Ubuntu, jinde za to neručíme.) Zvlášť pokud si s sebou hra ponese všechny knihovny.

Samotný vývoj hry, mapy, zvuky a částečně testování jsou značné náklady, které se platí jen jednou. Do dodatečných nákladů pro Linuxovou verzi nepatří.

Navíc část problémů s HW kompatibilitou snad vyřeší Source engine a část bude společná s Windows.

Pokud by podíl hráčů byl ve srovnání s Windows poloviční, díky menší konkurenci by se kupovalo desetkrát více her, byla by dvojnásobná ochota platit a dodatečné náklady na Linuxovou verzi by byly 10 % z nákladů na kompletní vývoj Windowsové verze, pak by i ta platforma se setinovou základnou byla schopna poskytnout stejný procentuálně výnos. (Čísla jsou to vycucaná z prstu. Chci ale naznačit, že to není nereálné.) Navíc při rostoucí konkurenci nebo při dochazejících nápadech na nové hry bude vývoj nových her pro Windows méně atraktivní a výrobci budou víc upřednosťovat portaci pro Linux. Pravda, při klesající konkurenci na Windows, rostoucí konkurenci na Linuxu a dalších a dalších nápadech na nové dobré hry bude zájem spíš menší, závisí na okolnostech.

Náklady na podporu naopak nerostou proporcionálně k počtu licencí. Když máte deset uživatelů s Linuxem, potřebujete pár lidí na jejich support. Když těch lidí máte pět tisíc, stačí vám pořád těch samých pár lidí.
Náklady na portovávání jsou navíc k verzi pro Windows, a vydavatel si spočítá, kolik výnosů za ty náklady dostane. Podle mě nebude moc šťastný.

Source Engine je jeden z mnoha, problém to neřeší.

Každý máme svůj náhled, necheme to rozsoudit historii. Ale obávám se, že jako obyčejně budu mít pravdu ;)

"Ale obávám se, že jako obyčejně budu mít pravdu"

Haha, mam najit, jak jsi tady kdysi predvidal, ze budoucnost patri .netu a c#? A kde jsme ted...

Klid, ta jeho arogance je uz legendarni ;)

A vy myslíte, že budoucnost nepatří .NETu a C#? ;) Pokud narážíte na WinRT, tak to je jen náhrada za Win32. Psát v .NETu DB engine nebo driver FS je sice teoreticky možné, ale za současných okolností to není dobré pro výkon (což by se mohlo změnit až s čistě .NET kernelem).

Zkuste mi tedy vysvetlit toto (Wikipedia):

"Windows Runtime, or WinRT, is Microsoft's 2011 programming model that forms the backbone of the new Metro-style apps (also known as Immersive) in their new Windows 8 operating system."

Tak jestli vy WinRT chapete jenom jako "nahradu" Win32 api, tzn. vec na psani driveru nebo databazi, tak asi zijeme kazdy v jinem vesmiru. Nebo Wikipedia lze. Jak to chapu ja, tak je vlajkove API pro Windows 8, bez ktereho byste ty uzasne dlazdicove aplikace tezko psal. Ale vy to pravdepodbne vydite jinak...

"Native C++ is a "first-class citizen" of the WinRT-platform."

Spojenim techto dvou vyroku (za predpokladu, ze jsou pravdive) opravdu tezko muzete tvrdit, ze budoucnost patri C# a .NETu.

Sam Microsoft kdesi tvrdil, ze se vraci k nativnimu kodu kvuli mensim narokum a setreni energie. Odpiskal Silverlight. Takze jestli doufate, ze nekdy ve strednedobe horizontu prijde navrat .NETu jako vseobecnemu API a dokonce .NET kernel, tak jste asi opravdu beznadejny optimista.

No nevím, z toho, že nativní C++ je first class citizen se těžko dá usuzovat něco o .NETu.

Tak se nad tim zkuste zamyslet.

I kdyz tady Lael cosi placa o tom, ze WinRT je jenom pro psani ovladacu a databazi, tvrzeni MS je diametralne odlisne a pro ne je WinRT jednoznacne vlajkove API pro jejich Win8 a Metro aplikace. Odklon od .NETu a C# je snad jasny, ne?

Kdyby mel byt C# (jazyk) a .NET (api) dal technologii cislo jedna, proc by zavadeli nove API (WinRT) a tvrdili, ze je pro ne C++ "first class citizen"?

Podle me(a nejen me) je to jednoznacne u-turn a naprosty navrat ke korenum a odsun .NETu mozna nekam na servery.

Nekdo to popisoval bojem dvou divizi v MS, kde jedna propaguje C++ a nativni kod a druha C# a managed kod. Ted pry zrovna vyhrala ta prvni...

V zásadě to zatím není ve sporu s tím, že by .NET byla jedna z možností pro WinRT a že by to bylo taky first class citizen. Třeba to finálních Windows 8 dají defaultně i .NET.

Neříkám, že se tak stane, jen říkám, že z uvedených informací nevyplývá, že se tak nestane nebo že se .NET odsune na druhou kolej.

Ale jakto? Neplette si .NET a C#. NET je API, c# je jazyk. A WinRT je API. Jak si predstavujete, ze .NET API bude moznosti pro WinRT API? Bud budete pouzivat pro vase programy .NET nebo WinRT. Kdyby .NET bylo vhodne API (spolu s managed kodem, VM atd.) pro Metro aplikace, tak by jej MS pouzil. Misto toho si zavedl uplne nove, vhodne pro nativni kod. Nejsem na toto expert, ale diky rozdilne povaze obou pujdou asi tezko kombinovat.

Pokud dam tolik penez do vyvoje API a s nim souvisejicich veci, tak pokud bych s nim byl spokojeny, nezavadel bych neco uplne jineho. Coz MS udelal a tim rika, ze .NET byl krok vedle. Jak to cist jinak nevim...

Ve Win8 asi bude .NET z duvodu kompatibility. Ale uz ne jako preferovane API pro psani novych Metro programu.

+1 Windows 8 by klidně mohlo používat C++/CLI. Ale .NET už zřejmě není směr MS.

WinRT je evolucí .NETu. Mohl jste si všimnout, že WinRT components používají metadata .NETu, ať už jsou psané v jakémkoliv jazyce, a používají type system korespondující s .NETem. Výsledkem je situace, kdy můžete bezešvě (to je česky?) kombinovat kód v C#, JavaScriptu a C++/CX. Výkonově kritické komponenty, například DB server nebo HTML renderer, budou nejspíš napsané v C++/CX. A front-endy s formuláři a grafikou budou typicky psané v C#/.NET. Nakonec na té Wikipedii najdete i tohle: WinRT supports XAML-based .NET Metro-style applications which are primarily written in C# and VB.NET (and for the first time for XAML with Native Code using C++/CX).

Můžete si také všimnout, že research project Singularity OS v posledních iteracích řešil otázku kombinace managed a nativního kódu. Díky použití .NET metadat je ve WinRT situace taková, že je aplikaci úplně jedno, v jakém jazyce je ta která komponenta napsaná. V další fázi můžeme čekat "úklid", tedy model checking většiny komponent, končící u kernelu.

Stejně by mě zajímalo, proč MS vymyslel C++/CX, když už má C++/CLI, které umí to samé (včetně unmanaged kódu), jen je to postavené nad .NET.

No, sice muzu kombinovat ruzne komponenty z ruznych jazyku, ale proc bych to mel sakra delat? Jenom proto, ze to jde? To, ze je neco podporovane, jeste neznamena, ze to tak ma byt primarne pouzito. To je spis z duvodu zpetne kompatibility, z ruvodu interoperability mezi ruznymi dodavteli, ale jako vyvojovy model pro nove projekty dost tezko.

Rekneme, ze pisu aplikaci typo Photoshop (nepisu, ale to co delam je podne - pulka gui, pulka vypocetni kod). V cem to mam teda podle vas psat?

Mam psat vypocty v C++ a GUI v C#? Jenom proto, ze prostredi si s tim poradi, se mam ja zblaznit a prechazet mezi dvema jazyky? Nebo proto, abyste mohl tvrdit, ze .NET neni na vedlejsi koleji?

A v cem mam psat dlazdicove metro?

Microsoft jasne rekl, ze "C++ is frist class citizen". Ja to ctu jako to, ze tento jazyk bude pro MS primarni a nejvic podporovany. Proto, ze VM a managed jazyky berou moc prostredku. Pak nevim, proc bych mel cas ztracet cas cimkoliv jinym a jeste to dokonce kombinovat mezi sebou.

A proč byste psal třeba účetnictví v C++/CX, když je to složitější a na chyby náchylnější prostředí, než C#/.NET?
Aplikaci typu Photoshopu můžete napsat kompletně v C#, což ukazuje třeba Paint.NET. Filtry byste ale stejně psal v unmanaged C#, a stejně dobře je můžete napsat v C++/CX (klidně jeden v C# a druhý v C++/CX). Pro každou část si můžete vybrat ze C#, VB.NET, C++/CX, a v budoucnu z dalších jazyků.
Tenhle model je nakonec používaný už delší dobu. Když píšete třeba informační systém pro nemocnici, tak ho napíšete v něčem typu C#, VB.NET, historicky VB, Delphi, C++Builder apod. A například komponenty pro zobrazování dat z RTG a CT mohou být v C++/CX. Typicky vám je dodá externí firma, v každém případě na tom budou dělat jiní lidé. Ve WinRT je model podobný, jen je ta integrace je snazší.

Nevšiml jsem si, že by C++ bylo na chyby náchylnější než C#, snad s tím rozdílem, že aplikace v C++ padají na segmentation fault a v C# (a Javě) na OutOfMemoryEx­ception.

No tak to jste si všimnul špatně. V C/C++ je velmi jednoduché udělat chybu. Pointery mohou ukazovat kamkoliv, snadno zapíšete za hranice pole nebo struktury, a existuje nespočet drobností typu if (a=1) (který vždy projde), switch fall through apod. V C# nebo Javě těžko uděláte buffer overrun, a garbage collection vás uchrání před většinou resource leaks.

V C++ jsou nejhorsi pretypovani. Prakticky se bez nich neobejdete a ztracite tim typovou kontrolu provadenou kompilatorem. Dalsi kapitolou je problem rucni spravy pameti a zdroju.

Kdo si mysli ze C++ ma stejnou chybovost jako C# tak pravdepodobne nedelal na zadnym vetsim projektu ktery ma statisice radku.

Pokud máte na mysli přetypování (Type)value, tak ano, to je taky prasárna^Wpozůs­tatek po C. Pomocí static_cast a dynamic_cast typovou kontrolu neztrácíte.

Momentálně dělám na projektu, který má cca 250 000 řádků C++ a cca 300 000 řádků Javy a moc velký rozdíl v chybovosti mezi těmi jazyky teda nevidím

S dynamic_cast máte typovou kontrolu jen za běhu, se static_cast ani to. Ano, s dynamic_cast na tom jsem skoro* jako v Javě, ale tam to nemusím moc používat, protože APIčka na to jsou připravena a nemusím používat nic jako *void.

Vývoj v Javě je jednodušší ve více věcech. U OOP třeba odpadá nutnost řešit hlavičkové soubory, není potřeba řešit přímo includy (akorát importy - IDE dost pomůže), můžu v asi libovolném IDE prostě vytvořit třídu a nestarat se kvůli tomu o vytvoření souboru (IDE pořeší podle konvencí). No nevím, ale ačkoli Javu jako jazyk až tak nemusím (Scala je někde jinde...), přijde mi mnohem pohodlnější než C++. Někdy přímo kvůli jazyku, někdy kvůli podpoře IDE (pro Javu stačí náhodně zvolit, pro C++ jsem se nahledal).

*) dynamic_cast řeší chybový stav NULLem, JVM pomocí ClassCastException.

dynamic_cast vyhazuje std::bad_cast, pokud castujete reference. A pointery byste castovat neměl, pokud k tomu nemáte speciální důvod.

Je pravda, že u C++ je s IDE problém, protože jich spousta není nic lepšího než editor se zvýrazněním syntaxe, ale třeba s KDevelopem taky nemusím řešit includy, protože je doplňuje sám.

No a jaky jsou nastroje na vyhledavani chyb v C++ ve stylu Findbugs a PMD (kdyz bereme jen ty opensource).

Problemem C++ je i to ze sice novejsi revize C++ umoznuji hezky veci, ale knihovny na to nejsou prizpusobene a tak se to nepouziva.

Dalsi veci jsou exceptions, vetsina knihoven to nepouziva aby se vyhnula resource leakum.

Javovsky projekty co tu mame jdou malo kdy pod milion radku, Nejvetsi C++ veci tu maji 600k a 850k - vyvoj uz jde dost pomalu.

Pokud je programátor prase, tak to posere v libovolném jazyce, i když je pravda, že C# mu to trošku znesnadní.

Raw pointery není radno v C++ používat a chytré pointery si tohle hlídají. To samé s raw poly.

Jak v C++ zapíšete za hranici struktury?

if (a=1): -Wall -Werror a pá pá ;-) (No, je možný, že MS kompilátor tady zaspal)

Ach ano, ono je v managovaných jazycích tak strašně těžké nevědomky udělat cyklus odkazovaný z nějaké statické proměnné (ukázka pro Javu, ale určitě to půjde stejně i v C#) ;-)

Smart pointery - pokud s tím nějaká knihovna nepočítá, tak to moc práce neusnadní. (Jak kdy.) Navíc při reference countingu je potřeba dát si pozor na cykly.

K if(a=1): to je dobrá věc, Java zde ale jde trošku dál s typovou bezpečností - požaduje boolean.

Cyklus v JVM ani .NETu nevadí (v PHP už dokonce taky nevadí - od 5.3), problém je spíš ten neodregistrovaný listener.

A psal jste někdy v Javě? if (a != 0) ááááá... Pořád, pořád, pořád. A to už jsem v ní víc než rok nucen programovat. :-(

#define IF(x) if((x) != 0) // nejdeeeeeee :-!

No a? S a!=0 nemám problém, při čtení je to mnohem víc vypovídající než if(a).

V C je to ještě celkem OK, ale potkat if(a) třeba v PHP...

Rozdíl mezi C# a .NET znám. (Mimochodem, .NET je platforma - nejen API, ale i bytecode.) V principu ale není problém volat WinRT API z .NETového bytecode. Neřeším teď, jak to technicky provést. Tuším, že .NET má vyřešeno volání nativních knihoven jednodušeji než Java (bez dalších knihoven).

a) .NET a C# jsou naprosto neperspektivní technologie, podobně jako ASP. Sám Mrkvosoft je potají nahrazuje novými (šmejdy).

b) Pravdu jste zatím téměř nikdy neměl. Mám Vám např. připomenout, jaký jste předpovídal výsledek soudního sporu Oracle-Google? LOL!

c) Portace jakékoliv hry na Linux vychází cca na 0 % nákladů, pokud použijete při jejím návrhu a implementaci multiplatformní technologie a NE Mrkvosoftí šmejdy.

a) ASP nahradil MS novějším ASP.NET, který s ASP moc společného nemá. O dalším nahrazování zde nevím. Ano, MS přišel s Razorem (nebo jak se tomu říká), ale to nejspíš nemyslí jako náhradu ASP.NET. (Mimochodem, nejede Razor taky na .NETu?)
Je možné, že .NET čeká něco podobného jako Javu - na desktopu se moc neuchytí, ale na serverech ano.

Do b) se míchat nebudu, statistiky si nevedu.

c) Diskutovali jsme situaci, kdy se při vývoji použije multiplatformní Source engine a Steam. I tady jsou nějaké dodatečné náklady. (Ale nebudu se opakovat.) Čím nižší, tím lépe pro hráče na Linuxu.

Volba enginu a technologií je taky otázka nákladů. S některými vyjde vývoj dané hry (aplikace, IS, ...) levněji a s některými dráž. Pochybuju, že bude mnoho firem volit striktně multiplatformní engine a knihovny jen kvůli tomu, že jsou multiplatformní. Sama multiplatformnost je určitě výhodou, ale striktní volba multiplatformního řešení je asi jako "dát přednost analnímu sexu, protože je multiplatformní". Multiplatformnost je výhoda, ale ne dogma. Pokud z možností vybereme a) tu nejlepší multiplatformní a b) tu nejlepší pro Windows (volba bude samozřejmě podle toho, co chceme vyvíjet apod.), mohou nastat tyto situace:
i) Obě možnosti jsou stejné, pak není co řešit. Náklady na volbu multiplatformního řešení jsou nulové.
ii) Vybíráme mezi multiplatformní (ale horší) a jednoplatformní (ale lepší). Náklady (nebo snížené příjmy) tu v nějaké podobě jsou.

Další náklady budou i u "multiplatformního řešení zdarma" (tedy v situaci, kdy bych multiplatformní řešení vybral, i kdyby mi na této vlastnosti vůbec nezáleželo). Protože nic multiplatformního není multiplatformní dokonale (snad ani Brainfuck), je potřeba testovat, řešit nekompatibility, je potřeba - vlastně se to již řešilo. Multiplatformní řešení tyto náklady umí snížit (pokud to není úplný sh*t), ale asi ne na nulu.

Dále tu jsou tzv. náklady obětované příležitosti. Názorně: můžete svůj vás investovat do práce se mzdou 50 CZK/hod. Uděláte to? Pokud nemáte k dispozici lepší práci, asi ano. Pokud máte jinou nabídku práce se mzdou třeba 1000 CZK/hod, budete kvůli nákladům obětované ve výši 1000 CZK/hod tratit (ve srovnání s možností lepší práce) 950 CZK/hod. (Pod mzdou mám namysli "superčistou mzdu" - po odečtení nákladů na cestování (i časových), započítání vlivu pracovního prostředí na zdraví apod. Patří sem samozřejmě i nucené náklady - daně.) Podobně to funguje u portace hry na jinou platformu - i pokud by to bylo ziskové, může to být málo, pokud dojde třeba k 1% zhodnocení. Vývoj nové hry poskytne nejspíš větší zhodnocení (to poskytnou i spořicí účty, aspoň u některých měn, takže asi jen blázen by se kvůli 1% zhodnocení pouštěl do vývoje hry).

Dodatečné náklady tu tedy jsou, dodatečné příjmy samozřejmě taky. Je pak jen otázka, jestli dodatečné příjmy budou vyšší než dodatečné náklady (včetně nákladů obětované příležitosti). Pokud ano, vyplatí se to, pokud ne, nevyplatí se to.

no zatial to nevypada tak, zeby mu buducnost mala patrit viac nez teraz. Svoj podiel uz ma a vobec to nevypada tak, zeby mal v buducnosti rast (nepocitam mobilne platformy). Inak co sa tyka winrt, tak od toho si M$ naozaj slubuje vela. Pre mobilne platformy to bude hlavna vetva a vobec to nevyzera tak, zeby bolo pouzitelne iba pre pisanie nejakych driverov.

V případě telefonické podpory by muselo být relativně víc lidí pro Linux, v případě "odpovíme do tří pracovních dnů" ani ne.

> Source Engine je jeden z mnoha, problém to neřeší.
Dokud Linux bude trhem jen pro část her, není to problém: budou se portovat primárně ty na Source engine. A pokud časem bude Linux větším trhem pro hry, myslím, že se portuje mnohem víc enginů.

> necheme to rozsoudit historii
Tak nějak.
BTW: Já jsem neříkal, že to bude mít úspěch. Já říkal, že to není až tak nereálné, jak se může zdát podle podílů obou platforem. Neřeším to do detailů, nemám akcie herních firem.

Ha! Slabé 1%? ?? ??? FUD? ?? ???

Pokud vyrobci her portuji pro Mac, coz je unix system, proc by neportovali pro linux? Mezi temito platformami nejsou zase takove zasadni rozdily IMHO :-)

MacOS má unixové jádro (protože společnost Apple nebyla schopná vyvinout nic lepšího), ale primární API nemá s UNIXy nic společného.

> MacOS má unixové jádro (protože společnost Apple nebyla schopná vyvinout nic lepšího)

To ešte nikto ;-)

> ale primární API nemá s UNIXy nic společného.

Z pohľadu hier má Mac rozdielne hlavne API pre zvuk. Okienka hry príliš neriešia a OpenGL je proste OpenGL. Najväčší problém bude mať samotné Valve a to s portáciou klienta. Najväčší ale neveľký, nakoľko je ich GUI kompletne postavené na Webkite a ne-grafická časť pre linux už dávno existuje.

Lael Ophir.
Pravidelná dávka sra*ek od ubrečeného Widláka.
Tak když tolik Linuxu závidíš, tak si ho nainstaluj.
My se na tebe zlobit za to nebudeme.

Vse zacina prvnim kruckem...

btw, me vzdycky fascinovalo, jak woknari lezou na stranky o linuxu

"btw, me vzdycky fascinovalo, jak woknari lezou na stranky o linuxu"

Mám úplně stejný dojem :-) Ale k tématu - snad ten první krok motivuje i ostatní, přeci jen je to signál, že Linux už nelze vnímat jako minoritní platformu.

To je tím že existují určité druhy lidí:
- linuxáci s klapkami na očích co se štítí čehokoliv od microsoftu a jsou schopni používat sebeobskurnější sw jenom proto že je svobodný

- lidi s nadhledem co dokáží využít nejlepší z obou systému a volí nástroje podle účelu a efektivity

- windowsáci co se štítí čehokoliv co vypadá jako příkazová řádka a jsou schopni používat sebeobskurnější program jenom proto že je od ms.

Srandovní je že první a poslední skupina se nesnáší alůe přitom jsou úplně stejní:-)

Ja myslim, ze se nesnaseji vsechny skupiny navzajem :D

definuj výhodnější

IMHO většina lidí používá to co jim strčí prodejce nebo zaměstnavatel

;-) čemu nerozumíš na "pro něj nejvýhodnější"

Subjektivně výhodnější. Kdyby pro mě byl výhodnější Mac, Linux nebo něco jiného, není důvod se držet Windows. Jsem pragmatik.

Co pro mě znamená výhodnější? Výrazně méně času stráveného neproduktivním rýpáním v systému, větší nabídka i lepší kvalita aplikací (BTW včetně her), lepší komunikace s okolím. Tj. vím jestli grafická karta, scanner nebo WiFi karta bude fungovat, můžu používat Outlook, Visual Studio, Photoshop a další profi aplikace, nemusím řešit problémy s otevíráním a ukládáním souborů MS Office, MS Projectu atd. A když chci (jako že většinou ne), můžu jet i bash, Apache, Gimp, OpenOffice, X11 server, a v podstatě všechno zajímavé, co je k dispozici pro Linux.

Z open source aplikací tu mám Ghostscript, Audacity (příšernost), Gimp (ještě jsem ho nevyhodil - fuj!), KeePass (skvělý), nějakou virtuální PDF tiskárnu (funguje), a tím to asi končí. Spoustu open source balastu jsem odstranil, protože by aplikace byly příšerné, polofunkční nebo nefunkční.

No zřejmě je výhodnější pro psaní příspěvků na Roota :-)

Jinak s tím hardwarem je to spíše zbožné přání. Jediný větší rozdíl je snad v tom, že pokud ten hardware nejde pod Windows, můžete ho vrátit do půl roku po koupi, u Linuxu máte jenom čtrnáct dní.

Rozdíl je v tom, že pro Windows existuje certifikace HW, takže si můžete vybrat něco, co bude fakt fungovat. U Linuxu je vyjma nepodpory spousty HW problém také v tom, že nikdy nevíte, co bude fungovat. Nejvýš se někde dočtete, že to Frantovi doma fungovalo (na distru X ve verzi Y), což ale vůbec nic neznamená. Já si po úspěšném vyhledání své WiFi karty v nějakém amatérském Hardware Compatibility Listu užil svoje s madwifi.

Špatně jsem se vyjádřil. Pokud vám certifikovaný hardware nefunguje, můžete jej do půl roku vrátit (rozpor s kupní smlouvou), jinak máte zase ty dva týdny. Ty doby znám z vlastní zkušenosti, protože už jsem několikrát zažil, že ani certifikace nezaručuje, že to po příští aktualizaci Windows stále bude fungovat.

Ne, že to nic neznamená. To znamená, že to Frantovi doma fungovalo na distru X ve verzi Y.

takovejch vědomě spokojenejch uživatelů widlí jako seš ty je ale dost málo, u ostatních je to spíš tak, že jedinou alternativou k xpčkám sou sedmičky (a naopak), některý dokonce zaslechli o vistách (wow) a ty největší frajeři (většinou majitelé iPhone) znají masox, ty movitější si i koupili od apple železo

když pominu ty frajery, tak pro drtivou většinu populace znamená "výhodnější" zůstat u toho co dostali od výrobce (zaměstnavatele, napirátil jim to kámoš, přibrnkla jim to Nigerijská vláda místo Mandrivy, etc) prostě protože neznají alternativu; s kvalitou to nemá nic společnýho, de jen o marketing

já taky nemam rád neproduktivní rejpání v systému, ale v systému se teď rejpu míň než když sem doma provozoval widle; všechny neproduktivní chvíle* který trávim u počítače se odehrávají v práci, kde sem nucenej používat sedmičky (což mě samo o sobě nedonutí změnit zaměstnavatele nebo projekt kterej hákuju)

* nejedná se o rejpání v systému (to maj na práci administrátoři), spíš čekam až mě antivir pustí na disk, až se otočí win server kterýmu došla paměť (oslí můstek na oom killer), až se mi otočí desktop protože jinak instalovat aktualizace nejde a podobný malý kopance

domácí uživatelé jsou self-admini, a pro ně Linux opravdu není dvakrát vhodný. Tedy pokud nemají někoho, kdo se jim o počítač zdarma stará, aby slavně šířil Linux.

Pokud chcete produktivní práci na Windows, vyplatí se mít spoustu paměti (je směšně levná), a samozřejmě SSD (o něco dražší). Pokud Windows Server udojde paměť, můžete procesy zabít vzdáleně. Hlavně se ale vyplatí zjistit, která nevychovaná aplikace vám tu paměť žere. Jo a instalace aktualizací se bude dělat s restartem - pro jistotu dvojitým - i ve Fedoře. Ona toiž aktualizace používaných souborů může vést ke značným problémům.
http://www.root.cz/zpravicky/fedora-18-predstavi-offline-aktualizace/

člověk kterej se nepostará o widle se nepostará ani o nic jinýho (a naopak), ale teda nechápu jakou to má souvislost, nepsal sem jen o domácích uživatelích a už vůbec ne o administrování, to až okrajově v tý druhý části textu (já taky nemam rád neproduktivní rejpání ...)

ale když už si mi to vnutil ...

zdarma se staram o tři počítače v rodině, na jednom je openSUSE (instalace přímo na vyžádání, dodaný OEM widle už tam majitelka nechce ani vidět) na dalších dvou xpčka a sedmičky, na nich řešim tu a tam něco, ale hlavně proto že jejich uživatel je ultra BFU

stroj s openSUSE měl jedinej problém s wifi a to že majitelka brnkla do čudlíku a tim si jí vypnula (a nevěděla o tom, přizvanej kámoš - widlák - na to čučel jak puk dvě hodiny), je to takový to velký pádlo od HP a celá ta řada tlačítek navíc tam fungovala out-of-the-box, to jen tak mimochodem (opakuju že to bylo koupený s OEM widlema 7)

ad paměť:
1. ten problém se vyskytne tak jednou za měsíc, kvůli tomu nebudu u korporace škemrat aby jí z 16G upgradoval vejš
2. SSD - hehe, to určitě, nejsou ani na produkčních strojích
3. na vzdálený zabíjení sem malej pán, neadministruju to
4. která aplikace to žere, hmmm takskmanager mi tou dobou už nešel spustit, následně vytuhl celej rdesktop, ale netvrdim že neexistuje jiný řešení

ad restarty - značný problémy mají asi jen widle a fedora, co má bejt

myslel sem že se tahle diskuze bude odvíjet nějak kostruktivně, ale zase si nezklamal, meleš furt ty samý bláboly (kup si paměť; kup si SSD; widle sou super, když máš problém tak je admin nekompetentní idiot; negativní vlastnosti pronikají i do linuxu; linux nefunguje na žádným HW; atp.)

neproduktivní rejpání v systému tě sere, ale neproduktivní opakování těch samejch věcí (neřku-li lží) lidem který to nezajímá ti vůbec nevadí

nazdar

1. Pokud se problém vyskytuje jednou za měsíc, tipnul bych si na schedulovanou kontrolu antivirem. Ve firmách celkem běžná věc. Bohužel s tím těžko něco udělat, pokud nemůžete ten stroj administrovat. Bylo by super, kdyby autoři antiviru alespoň prováděli kontrolu s nízkou prioritou I/O operací, a nezbili tak uživateli práci na desktopu.
3. Jinými slovy problém asi není ve Windows.
4. Samozřejmě existují alternativy. Můžete například pustit Performance Monitor a připojit se k tomu stroji.
5. O aktualizacích píše Richard Hughes následující: "just try updating xulrunner when Firefox or Thunderbird is open". Podívejse se na sekci "So why bother with all this?" v tomhle dokumentu:
http://blogs.gnome.org/hughsie/2012/06/04/offline-os-updates-looking-forward-to-gnome-3-6/

1) To by ale ten antivir nesměla být uzavřená aplikace. Třeba s ClamAV to totiž není problém.

5) To jenom dokazuje, že ani placení vývojáři ve Fedoře neumí udělat fungující aktualizace, protože třeba v Debianu a Ubuntu tenhle problém není ;-)

1. Třeba s Avastem to také není problém, tedy když to tak nakonfigurujete.
5. Aha. A jak se v Debianu a Ubuntu řeší případy, kdy se běžící knihovna nahradí jinou verzí, a dva různé worker processy používají různé verze knihovny? A jak se řeší, když aktualizace nahradí běžící knihovně resources, které nejsou zamčené, ale se kterými při běhu počítá? Tipnu si: nijak.

Protože dpkg soubory nepřepisuje, jak je zvykem ve Windows, ale pomocí atomické operace move nahrazuje, tak oba worker procesy používají starou verzi knihovny, dokud daného démona nerestartujete. Stejně tak resourcy stačí, když jsou otevřené, vůbec je není potřeba zamykat.

A když se nastartuje nový worker a ten natáhne knihovnu, která se v daném místě nachází? A když knihovna resource file nemá momentálně otevřený, a otevře ho později?

Když se používá forkování, jsou všechny knihovny načítány před forkováním, jinak forkování bude žrát spoustu paměti. Samozřejmě pokud by se spustil úplně nový worker přes exec, bude mít už tu novou knihovnu, ale ani s tím není problém, i kdyby totiž načetl stejně knihovny, kvůli randomizaci paměťového prostoru bude výsledná binárka taky úplně jiná, takže když už se to děje, tak se s tím počítá.

Resourcy se většinou otevírají rovnou při startu, aby už při startu se ověřilo, že žádný nechybí. Třeba ten Firefox to tak dělá.

Takže když dvě instance procesu používají různé knihovny, podle vás to není problém? A když běžící procesy a knihovny zůstávají děravé do příštího rebootu, také to není problém?
Aplikace může a nemusí otevírat svoje resources při startu. Zrovna Firefox je uváděný jako příklad aplikace, která to nedělá.

Po dokonceni bezpecnostnej aktualiziacie sa samozrejme dotknuty demon restartuje. Niektore distra (debian a odvodene) to dokonca robia automaticky. Ale restartuje sa JEDEN demon, nie cely system. Nie sme ani blazni, ani za Windowsom.
A to, ze ako priklad aplikacie nezvladajucej updaty uvadza firefox bude dovod, preco toho chlapa nikto neberie vazne.

Mimochodom, co ma toto vsetko spolocne so Steamom?

To můžete samozřejmě úplně stejně udělat i ve Windows (akorát je to stop-update-start). Problém je, když se aktualizuje něco, co je využíváno více programy. Třeba sdílené knihovny.

Co to má společného se Steamem? Asi nic. I když Steam se ve Windows prostě po aktualizaci restartuje.

stop-update-start samozrejme nieje "úplne stejné", stop-update-start znamená kľudne i niekoľko minútový downtime alebo užívateľa otráveného čakaním. A áno, steam je na zdĺhavé aktualizácie expert, našťastie má aspoň toľko slušnosti, aby sa pred aktualizovaním spýtal.

Ne, proč by to byl problém?

Slušné distribuce nabízí možnost restartovat služby, kterým byly aktualizovány knihovny. Některé to dokonce dělají automaticky (Debian a na něm založené, lze vypnout).

Aplikace by měla buď otevírat resources při startu nebo by měla umět zvládnout, pokud se za běhu změní. Co když je někdo za běhu smaže?

Možná je FF uváděný jako příklad, ale není to pravda, FF pouze vybízí k restartu, aby se aplikovaly aktualizace.

1. nejde o desktop, znát je to i na sambě, AV kontrola tam běží AFAIK každej den (za úmyslný vypínání nebo libovolnou manipulaci s AV by mě nejspíš vyhodili), a rejpat se v systému mě stejně nebaví stejně jako tebe, otravovat někoho aby s tim něco udělal bylo ultra složitý i když sme byli ve větších sračkách
3. asi ne, ale bez widlí by ten problém neexistoval
4. super, to aní jako echt pruda, třeba to někdy zkusim (spíš ne)
5. ze zmíněnejch softwarů používam jen FF, nikdy sem nepozoroval žádný abnormality, kromě updatu flashe (a abnormality pokračovaly i po restartu, flash je mimořádný kurvítko)

takže díky za rady, ale už se o to nepokoušej, nevíš co dělam a pro koho pracuju, takže rozdávej svý rozumy jinde někomu kdo to ocení

OK, postěžoval jste si, a pokud to stačí, tak tím končíme.

pokud si ještě nechceš postěžovat na kvalitu open source sw, tak asi jo

Clovece nestastny, v akom casovom pasme to zijes a preco o stvrtej nad ranom na roote vysvetlujes, ze si uviazol za Windows? O.o

Časové pásmo? To je různé :). Jinak já jsem na Windows neuvíznul. Mohlo by být lépe, ale nikdo mi nic lepšího nenabídnul.

Pravdupovediac, skutocne ma zaujimalo, co za cloveka sa to uprostred noci loguje na linuxovy server, aby tam kazal o vyhodach Windowsu a nizkych sancach linuxu na cokolvek...
Po citani dnesnej diskusie mam pribliznu predstavu a povedal by som, ze uviaznutie na Windows je tvoj najmensi problem.

Na záhlaví stránky vidím psáno "informace nejen ze světa Linuxu". Nesouhlasíte s nějakým mým názorem? Klidně to napište, diskusi se nebráním.

Ale iste, az sa diskusia zvrtne na Steam a jeho buduce posobenie na Linuxe, rad sa zapojim ;)

já bych se rozhodně nebránil lepšímu systému, kterej by navíc byl za prachy, jenže widle pro mě takovým systémem rozhodně nejsou

no vidis, ja by som bral linuxovy system za prachy windows s tym ale zeby ten linux na desktope fungoval perfektne (tj ako windows)

SW není náboženství

Teď jsem se málem udusil kafem. Zrovna od tebe bych podobnou větu opravdu nečekal.

Tak minoritní bude i po tom, co bude steam na Ubuntu, protože pochybuju, že se tím výrazně zvýší podíl nainstalovaných linuxových OS na PC.

Jenomže tento je profesionální troll.

Tak herni platforma je pro me neco, na cem bezi Uncharted, Killzone a Heavy Rain. Proste neco, na cem se da hrat, sednou k telce a jet :)

Jj, až bude něco jako Uncharted na Windows nebo Xboxu, tak to možná bude něco jako moderní herní platforma :-)

a mozno by neboli zle aj nejake tie ovladace na grafiku ktore aj vykon HW budu vediet vyuzit :)

Docela by mně zajímalo, jak budou do budoucna řešit kompatibilitu svých her s novými verzemi knihoven. To budou s každou novou verzí Ubuntu všechny hry překompilovávat nebo mají v záloze nějaký middleware, který zajistí že pokud bude v systému správná verze Steamu, tak pak už hry půjde spustit bez ohledu na tom, co se pod nimi bude měnit?

Tak ako to Windows.
Skompiluju to staticky, pripadne pribalia spravne verzie kniznic k Steamu alebo hre.

Hura, vsechno bude hnit v /opt, pripadne /home/user... Proc rovnou nezalozit /program files a nenacpat obsah /etc do nejaky databaze.

Pozri, je to svet otvorenych moznosti, mas otvorenu moznost neistalovat si to.

Moznost #2 je, ze zverejnia Steam, Source engine a 20% pod GPL, vdaka comu si to kazde distro skompiluje proti aktualnym knizniciam a zabali tak, ako je potrebne.
Ale asi nie som sam, kto moznosti #2 nedava velke sance :p

Ja si instalovat nebudu, ale prijde mi, ze linuchova distra nejsou prilis pripravena na nejake closed-source binarni molochy, ktere si potahnou pulku systemu znovu s sebou. Uz to vidim: pro spusteni hry sourcnete v terminalu file xygamesettings.sh a hru nasledne spustte prikazem xygame.

http://pastebin.com/52jpePYV

(kua s enterom)

... riesis, co uz je davno poriesene. Closed source hry sa proste dodavaju takto, rovnako ako na Windowse, Macu a obcas i androide.

Jo a spusta sa to ikonkou ;-)

A co vrati du -hsc lib32 lib64?

956K libs32
1.3M libs64

a len pre porovnanie, 69M maju data a 14G v spravicke spominane left 4 dead 2 ;)

Byl jsi rychlejsi nez moje pochopeni tvych dat :-) Ja se bojim tehle situace:

du -hsc *
458M lin
473M lin64
930M total

Realna situace na mem vyvojovem pc; software ktery tohle vsechno tahne (vcetne vlastni verze glibc) je Xilinx ISE.

Desive cisla, uznavam, ale stale je to len asi desatina velkosti datovej casti priemernej hry na source engine.

Inak taky mini-vyhlad do sucastnej situacie hier na Steame:
- Steam si do Windows instaluje vlastnu sluzbu a dava ktoremukolvek uzivatelovi prava instalovat novu hru. Niektore hry este dnes spusta v profile Administratora
- Niektore (mozno i vacsina) hier "portovanych" na Mac su portovane cez Wine. To znamena, ze si ich instalacia nesie cele wine, minimalne jeden wineprefix a vsetky kniznice okolo toho
- Source engine pre Mac nebezi nad OpenGL, pouziva Valve vyvinuty wrapper. Vraj je malicky a vykonny. V kazdom pripade ale, kazda Source hra na Steame si nesie cely Source engine a ani dve nepouzivaju presne tu istu verziu.
- 99.9% hier na Steame pre Windows si nielenze nosi vascinu potrebnych kniznic, oni si nosia i instalator na DirectX, .NET, XNA, MS VC++ redistributable, NVidia PsychX... V sucastnosti mam na disku 10 steam hier a 11 kompletnych instalatorov pre DX10

A az teraz sa mozete bat ;-)

Kazda source hra si nenese cely engine, prave kvuli takovym pripadum ma steam .gcf soubory se sdilenymi daty, ve kterych udrzuje pouze nekolik majoritnich verzi.

Tieto subory ale nevyuziva ziadna zo styroch na Source engine postavenych hier, ktoru mam na disku. Skusil som spomenute .gcf pomazat a kazdu som bez problemov spustil (L4D, L4D2, Portal 2 a Nuclear Dawn)

No treba HL2, Ep1, Ep2 a Portal 1 engine a nejaka data sdili, ale ta usetrena velikost bude maximalne ve stovkach MB, coz je asi dneska zanedbatelne.

A staticke linkovani mam rad, myslim ze by se v Linuxu melo praktikovat vice (snad me nikdo neukamenuje :D). Opravdu nesnasim, kdyz kvuli nekolika aplikacim, ktere chci mit aktualni, musim zupdatovat cely system... (nebo nastavovat chroot)

Aha, beru zpet, z nejakeho duvodu jsem predpokladal, ze je ten vypis okousany na par prvnich fajlu. Nevsim jsem si ponozky "total".

Tipuju, že prostě řeknou, že podporují LTS verze. Například Ubuntu LTS, Debian stable. Něco jako u Skype

Zajímalo by mě, jestli se pustí i do jiných distribucí, nebo jestli to nechá nějakým způsobem na komunitě.

ze Lael Ophir bude mat asi velku odmenu, za propagaciu M$ technologii a to hlavne na portali, ktory sa zaujima o linux. Len tak dalej chlapce, ides na zamestnanca mesiaca ;)

Docela mě děsí představa, že to všechno myslí vážně a dělá to zadarmo - to by bylo na okamžitou hospitalizaci v léčebně s ostrahou.