Názory k článku
Valve potvrdila Steam pro Linux, nejprve bude pro Ubuntu

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

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.

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.

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...

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.

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

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.

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#) ;-)

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 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.

definuj výhodnější

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

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á.

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.

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

Č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.

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.

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.

A co vrati du -hsc lib32 lib64?

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.

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.

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".