Hlavní navigace

Microsoft: „hledáme open source evangelistu”

Sdílet

Pavel Chalupa 27. 12. 2006

Podle článku na Linux.com shání Microsoft „nadšence” pro Linux. Někdo z Microsoftu telefonoval příteli autora článku a sháněl pro Microsoft člověka na pozici „open source evangelist”. Pravděpodobně byl jedním z mnoha o kterého se Microsoft pokoušel.

Našli jste v článku chybu?
  • Aktualita je stará, nové názory již nelze přidávat.
  • 27. 12. 2006 16:03

    bez přezdívky
    No, ale jestli se nepletu, tak jednou z hlavních úloh 'M$ evangelist' je vzdělávat veřejnost (nejen své vývojáře). Docela by mě zajímalo, kam M$ poslední dobou míří. Spolupráce s Novellem, Linux školení, uvolnění zdrojáků jádra WXP pro akademické účely, ...
    Může to být krok správným směrem, ale tuším spíš zradu a nepochopení filozofie Open Source.
  • 27. 12. 2006 17:53

    bez přezdívky
    Nejspis je MS tak velky, ze jiz sam nevi kam miri a proste jednotlivi lide uvnitr se chytaji jednotlivych veci a prava ruka nevi co dela leva...
  • 27. 12. 2006 21:50

    bez přezdívky
    ja by som ich nepodcenoval. To byva najcastejsia chyba.
    prevdepodobne sa chystaju na pekne nekaly uder pod pas. (mozno nieco na styl infiltrovanie a zneskodnenie z vnutra)
  • 27. 12. 2006 19:05

    Branislaw (neregistrovaný)
    rozmyslali ste nad tym ze by spravili vlastne distro linuxu ?
    zoberu vsetko dobre z linuxu nakolko to je zadarmo :) naportuju aplikacie ktore budu uzatvorene obcas nieco zadarmo ... daju k tomu podporu a mame tu MS Linux zamozrejme kto by si ho nechcel vyskusat ? a v testoch bude lepsi,vykonnejsi a pouzitelny pre jednoducheho cloveka

    je to mozne ?
  • 27. 12. 2006 22:54

    Hynek (neregistrovaný)
    Jde vám o LINUX nebo o nenávist k MS? Protože distribuce MS Linux by bylo největší vítězství LINUXu. Nebo ne?
  • 28. 12. 2006 0:11

    K2 (neregistrovaný)
    A vy byste se vzdal systému, který generuje významné příjmy, a je technologicky nejpokročilejší na trhu? Ve Vistě je třeba transakční NTFS (plné ACID transakce nad FS), prioritizace I/O (navíc využívaná velkou částí systému), .NET Frameworkem (který zbytek IT světa bude dohánět dlouhá léta), obrovskou základnou aplikací a uživatelů? Dobrovolně takový systém odstřelit by bylo poněkud hloupé, a jít do kopie komerčních unixů, to by bylo hloupé, ne?
  • 28. 12. 2006 0:13

    K2 (neregistrovaný)
    Sem se na konci zacykli :). Což mě přivádí k otázce: co je tak špatného na Windows Vista?
  • 28. 12. 2006 0:34

    martin (neregistrovaný)
    hm... že je to nepříliš povedená kopie Mac OS X? Pokud se uchýlím k porovnávání, tak zjistím, že Mac je mnohem kvalitnější a použitelnější a po stránce designu hezčí systém; linux a obecně *nixové systémy mají zase kvalitnější zabezpečení a vyšší stabilitu, ovšem nižší uživatelskou přívětivost... Vista prostě není nic revolučního a bude vydělávat jenom díky reklamní politice Microsoftu. Takže podobná otázka: existuje vůbec nějaký relevantní důvod hovořící pro koupi systému MS Vista? Kdyby se operační systém pořizoval na základě kvality, tak bychom tu měli jenom Mac OS X, linux, unix a *BSD (můj názor)...
  • 28. 12. 2006 1:13

    K2 (neregistrovaný)
    MacOS X je technologická spatlanina. Je to vidět na problémech s výkonem, třeba na threadingu. Samozřejmě uživatelsky je na tom celem dobře, což je mimo jiné tím, že Apple vyrábí HW i SW. Fuj, monopol, ale běhá to.

    Důvod pro Vistu? Pro koho? Pro uživatele? Obrovská dostupnost aplikací, velká spousta HW. Pro vývojáře? Výrobná dokumentace, dobré vývojové nástroje, .NET Framework 3.0.
  • 29. 12. 2006 15:03

    bez přezdívky
    Nemám zkušenosti s MacOS, ale ty důvody pro Vistu jsi vystihl přesně. Bohužel, ergonomie ovládání z mého pohledu klesla hluboko pod bod mrazu a co jsem měl možnost vyzkoušet, zjistit a vidět, tak májí povětšinou vetší problémy s HW jak WXP.
  • 29. 12. 2006 15:17

    K2 (neregistrovaný)
    Ergonomie ovládání podle mě trpí u Start Menu. Posoudit to budu moci po delším použivání. Problémy s HW v betách (ostrou Vistu jsem nezkoušel) jsou celkem běžné. Je třeba, aby drivery uvedly výrobci i MS. Podle MS má Vista přibaleno více driverů, než měly XP. Nakonec s XP jsem kdysi jel grafiku a TV tuner na beta driverech ještě 3/4 roku po jejich uvedení, protože ATI nebyli schopni dodat finální (a hlavně bezchybnou) verzi. Přesto XP má dnes každý.
  • 29. 12. 2006 16:14

    bez přezdívky
    WXP má každý. Kvůli driverům, přeci jen trošku větší stabilitě a kvůli tomu, že W98SE už dlouho nejsou podporovanou 'distribucí' :)
    Nehledě na předinstalované systémy - noťasa jsem si musel koupit s WXP-Home. A i kdybych si chtěl připlatit za WXP-Pro, možnost jsem neměl. To je jeden z hlavních důvodů..
  • 25. 6. 2007 12:13

    anonymní
    Pánové, koukám že nkdy na konci roku 2006 tu byla doszti tupá argumentace co je lepší, jestli Microsoft nebo Apple. Rád bych tu slyšel opravdu úádné argumenty a né tlachání. Pokud někdo neví co MAC X versus Windows, nikdy němel možnost porovnat HW a SW těchto výrobců na akademické a vyšší úrovni, tak ať si nechá hloupé názory pro neznalé lidy kteří pracují a pracovali pouze na MS Windows. Nic proti MS Windows nemám ale uvědomte si všichni že Apple je na tom s HW stokrát léme než nějaká stupidní architektura na PC. Vždit je to stále stejná písnička na x86 a teď s k tomu přidala architektura s 64 bitovým CPU. Srovnáváte BMW a Volvo. Tak mi řekněte co je lepší z těchto dvou výrobců vozů. Každej si najde to co více vyhoví jeho požedavkům. Tečka za vším, servus.
  • 28. 12. 2006 1:54

    BLEK. (neregistrovaný)
    MAC OS X je hezčí?

    Dialogová okna z plechu, skleněné scrollbary, tlačítka na manipulaci s okny z barevné gumy, "roztékání" celého okna při minimalizaci --- může si někdo vymyslet ještě něco nevkusnějšího?
  • 27. 12. 2006 22:44

    K2 (neregistrovaný)
    Přijde mi to jako nesmysl. MS už měl Unix, konkrétně Xenix, a zbavil se ho. Windows jsou koncepčně pokročilejší, než unixy. NT mají HAL, modifikovaný mikrokernelový design, kernel je plně preemptivní a reentrantní, modulární, nativně podporuje thready, je objektově pojatý, má fungující asychronní I/O. Na úrovni API má MS řadu věcí typu GDI (a RDP), které unixy ještě pořád nedostihly. Má celkem slušné Win32, a velmi dobrý .NET Framework.

    Proč by proboha MS šel do kopie komerčního unixu, která je technologicky 40 let stará? Kdyby neměl vlastní slušné technologie (jako je neměl Apple), pochopil bych to.
  • 28. 12. 2006 0:32

    Tayto (neregistrovaný)
    A ktery nedostizeny unix mas na mysli? Totiz tech unixu je trochu vic nez jeden ty tunto. A urcite si vyberes ten ktery tve pozadavky splnuje. HAL uz byl v CP/M a v Linuxu je taky. Thready. A co NPTL? Misto GDI a RDP mame Xka. Kdyz uz tady necim argumentujes tak si o tom aspon neco precti.Asynchronni I/O uz se s jadrem 2.6 rozjelo.

    Stejne ty MS zkratky jenom takovy buzzwordy marketingovych vymatlancu. VPPFN(Very Proprietary Protocol For Nothing).
  • 28. 12. 2006 1:21

    K2 (neregistrovaný)
    Na prvním místě si nebudeme tykat.

    HAL (Hardware Abstraction Layer) je přesně ta věc, kterou Linux nemá. Naopak VMS ji měl. Něco si o tom přečtěte.

    Thready pomocí NPTL jsou naroubované nad procesy; ve Windows je jasné dělení thread-proces.

    Místo GDI *nemáte* X11. GDI je modul, který poskytuje aplikacím API pro kreslení, a komunikuje s drivery zařízení - grafických karet, tiskáren, plotterů... Každý driver zařízení má nějaké schopnosti, třeba kreslení čar, bodů, bitmap. GDI jako vrstva abstrakce ukrývá detaily driverů. Plotter třeba neumí nakreslit křivku, ale jen čáru a bod. GDI tedy volání pro vykreslení křivky převede na lomené čáry či body, apod. Samozřejmě lze pro kreslení po obrazovce, tiskárně a plotteru použít ten samý kód; stačí jen zaměnit výstupní zařízení. X11 technologicky cca 20 let pozadu.

    Asynchronní I/O se rozjelo o mnoho let později proti Windows, je velmi "očesané", a skoro nikdo ho nepoužívá. Windows používají async I/O samozřejmě i interně.

    Ty zkratky jsou důležité, pokud jim člověk rozumí. Pokud někdo uvíznul na 40 let staré příkazové řádce, jeho svět je nutně plný zášti k čemukoliv novějšímu.
  • 28. 12. 2006 8:08

    Peter (neregistrovaný)
    Asi zijem na inej planete nez Ty (tykanie je sucastou netikety a vykanie je aristokratickym prezitkom, precitaj si nieco o tom). Na tej "mojej" planete je evidovanych cca 270000 rozlicnych infiltracii pre Windows a ani jedna rozsirena pre Linux. V tom nie su zaratane ad- a spy- pretoze antivirusove firmy sa povacsinou tvaria, ze to sa ich netyka (pretoze keby pripustili, ze ano, museli by okamzite priznat porazku).

    Argumentovat pomerom na trhu ako jedinou pricinou nedava zmysel. Podla tej logiky by Apache musel byt omnoho zranitelnejsi nez IIS, vzhladom k trhovej prevahe. Podobne Mozilla Firefox mal schytavat aspon 60000 rozlicnych malware, kedze IE ich schytava pol miliona. Alebo aspon skromnych 5000? Alebo 500? Alebo 50?

    Vyvojovy model M$ je od zakladu zly. Vsetko vyvijaju v jednej kope, IE s OE a ostatnymi klikatkami spolu so systemom. Chyba v IE vypadne na uplne inej strane systemu. Graficke rozhranie spolu s notepadom. Lebo vraj "vsetko je sucast systemu". Sudnemu cloveku je jasne, ze takyto model nemoze fungovat. Jedno menu na vypnutie pocitaca potom prejde cez 43 ludi kym sa dovyvija do konca. Chyby sa jednoducho nedaju realne opravovat (schvalne si zisti, kolko vaznych bezpecnostnych problemov je v IE neopravenych uz niekolko rokov).

    Z toho vyplyva len jedno: ak je Window$ taky genialny system ako tvrdis, tak su M$ najvacsi babraci na svete.
  • 28. 12. 2006 10:59

    Juraj DURECH
    Hmm takze, ked ti dochadzaju argumenty, tak pouzijes oblubene poukazovanie na pocet chyb?

    Ja bych chcel len dodat, ze pokial sa reusuju komponenty, tak je viac nez pravdepodobne, ze chyba v komponente sa zakonite objavi vo viacerych aplikaciach. Co takto spomenut si na buffer overflow v libpng (http://www.securityfocus.com/bid/10857/info), kolko aplikacii a distribucii linuxu bolo pri tom postihnutych...
  • 28. 12. 2006 14:39

    K2 (neregistrovaný)
    Vykání je věcí volby. Je slušné druhou stranu v této věci respektovat.

    Malware je problémem. Pro Linux není rozříšený malware, protože není rozšířený Linux. Většina dnešních "virů" jsou červi, které si uživatel dobrovolně stáhne a spustí. Nevyžadují ani oprávnění admina - prohrabání pošty a dokumentů na emailové adresy, a následné rozesílání spamu admina nepotřebuje. Problém je v uživateli. Došlo to tak daleko, že Outlook úplně blokuje manipulaci (otevření, uložení, přeposlání, odeslání) executable souborů. Uživatelé jsou odolní - jsou schopní rozbalit přiložený ZIP heslem, které je v přiloženém obrázku, a malware přesto spustit :(

    Firefox je dnes už také cílem. Jsou tu exploity, je tu malware. http://www.internetnews.com/security/article.php/3624071

    Počet hacknutých Linuxů na netu je podle některých zdrojů vyšší, než počet hacknutých Windows.

    Vývojový model Windows je poněkud jiný, než si představujete. Windows jsou komponentové, takže třeba Internet Explorer jako aplikace jen sdružuje komponenty HTML rendereru, XML parseru, toolbarů, a celé to "lepí" dohromady. Tak vypadá code re-use. Samozřejmě problém v komponentě XML Parseru může postihnout serverovou aplikaci, MSIE, nebo obojí.

    Jinak GUI se nevyvíjí s Notepadem :). Na menu na vypnutí počítače se sice podílelo 43 lidí, ale zřejmě nad tou věcí strávili průměrně každý nejvýše pár hodin (sešli se na meetingu, nejspíše virtuálním). Navíc je to celé vyjádřením bývalého zaměstnance, tedy dost "divoká" informace. Jednou to bude pěkná urban legend - kterak 43 programátorů MS celý rok psalo jedno menu :)
  • 28. 12. 2006 14:25

    Field (neregistrovaný)
    Async I/O si Windows odnesly z VMS, stejne jako vetsinu zajimavych veci v originalnim navrhu NT. Cimz ovsem nerikam, ze Microsoft nema zajimave technologicke prvky, to vubec ne. Spis maji obrovsky problem v tom ty zajimave technologie ve fazi designu behem realizace totalne nezkurvit, to se jim proste nedari. Takze i u Visty ocekavam, ze vsechny ty zajimave prvky, na ktere jsem celkem zvedavy, budou mit hromadu velikych "ALE".
  • 28. 12. 2006 15:10

    K2 (neregistrovaný)
    Vztah Windows a VMS je velmi volný - na vývoji se podíleli stejní lidé. Mezi zajímavé prvky počítám nativní podporu více subsystémů (Win32, POSIX, OS/2), kvalitní VMD (Virtual DOS Machine, pro DOS a Win16 aplikace), modularitu, HAL, portabilitu, škálovatelnost.

    Zajímalo by mě, co podle vás MS "kurví" ve fázi realizace?
  • 29. 12. 2006 8:38

    Petr Baláš (neregistrovaný)
    Úplně vespod jsou si VMS a WinNT dost podobné ale Win není zdaleka jen vlastní jádro. Subsystémy jsou velice hezká idea ale zjistěte si současný stav a nejen to, jak to vypadalo v prvních verzích WinNT :-(.

    Pod "kurvením ve fázi realizace" bych si dovolil představit to, že někdo navrhne nějakou komponentu, vymyslí její rozhraní ale pak další vývojář (ať již v časové tísni nebo z blbosti) použije interní rozhraní a nebo se spolehne na nějakou v rozhraní nespecifikovanou vlastnost a tím efektivně zamrazí vlastní implementaci komponenty do jedné jediné možné podoby. V Linuxu je od naprosté většiny komponent více implementací a tak toto riziko nehrozí.
  • 29. 12. 2006 15:31

    K2 (neregistrovaný)
    Subsystémy musí být realizovány (minimálně částečně) v kernel mode, aby se zabránilo příliš vysoké frekvenci přechodů do kernel mode a zpět. Čistý mikrokernel zpravidla zabije právě ztráta výkonu díky příliš častým kernel transitions.

    Řekl bych, že do jediné možné podoby mrazí komponenty více vlivů. Dá dost práce komponentu nahradit, takže to zpravidla nikdo nedělá. Na Linuxu je to ale daleko drsnější - tam koncept snad ani neexistuje. Viz několikrát předělávaná podpora USB, kolotoč okolo podpory zvuku... Potom totiž reálně hrozí, že se pro Linux v podstatě nedá psát. Viz články tady na rootu o Adobe Flash a sjednocování linuxového desktopu, problémy jsou tam pojmenované.

    Ještě ke konceptu - stojí za zmínku, že pro Windows existují implementace Real Time, které nemění ani řádek zdrojáku kernelu. Prostě jen doplňují a nahrazují komponenty. Není tohle úspěch, ve srovnání s jakýmkoliv unixem?
  • 30. 12. 2006 20:36

    Petr Baláš (neregistrovaný)
    Ad subsystémy - narážel jsem spíš na to, že původně pod WiNT byly všechny subsystémy rovnocenné ale dnes už je ten Win32 primární a ostatní na něm závislé což tuto hezkou myšlenku poněkud degraduje. Ale teď koukám - zdá se že nějak netušíte, co to je subsystém protože subsystém pod WinNT opravdu běží v usermode. To, že WinNT nebyl zrovna čistý mikrokernel (drivery, filesystémy v jádře, ...) je na subsystémech nezávislé.

    Ad komponenty - já mluvím o komponentách na úrovni windowmanageru nebo SMTP serveru. USB bylo tuším že přepsané dvakrát, první implementace se neukázala zcela šťastnou a tak se to napsalo znova a lépe. IMHO je to mnohem lepší situace než skončit s blbou implementací něčeho co prostě nemohu přepsat korektně. Ad zvuk - starší je OSS, nová je Alsa ale ta umí bez problémů emulovat usermode rozhraní původní implementace takže kde je problém?

    Ad realtime Win - možná je to jen důsledek toho, že to prostě snadněji udělat nejde. Ale možná vám jen nerozumím - kdyžtak sem napište odkaz na technický popis toho, o čem tu básníte.
  • 2. 1. 2007 20:33

    K2 (neregistrovaný)
    Ad subsystémy - viz níže v jiném příspěvku. Ad mikrokernel - asi jsem už psal, že se jedná o modifikovaný mikrokernel. Čistý mikrokernel není výkonově udržitelný, protože ke transition do kernel mode dochází příliš často. Proto mají NT servery v kernel mode.

    Ad USB - domnívám se, že je nejlepší se nejprve zamyslet, a pak něco implementovat. Tím se podobné situaci zpravidla předejde (jenže to chce nějaký projektový management). Pokud to nevyjde, lze provést změnu mezi verzemi. Ad Alsa - pokud vím, je tam řada problémů.

    Ad RT extensions - snadněji než výměnou modulu to opravdu už udělat nejde ;). Ad popis - první link z google je tenhle:
    http://www.windowsfordevices.com/articles/AT5376962137.html
  • 6. 1. 2007 23:12

    Petr Baláš (neregistrovaný)
    Ad subsystémy - po odstěhování grafiky do jádra to opravdu není ani ten modifikovaný mikrokernel.
    Ad USB - zamyslení se je prima ale ne vždy se napoprvé vzprodukuje dokonalý produkt. To je prostě realita.
  • 28. 12. 2006 23:16

    Petr Baláš (neregistrovaný)
    HAL je hezká myšlenka ale zkuste se podívat na realizaci - kolik funkcí z HAL je nakonec implementováno jinde a kolik funkcí které byly původně jinde nakonec bylo přesunuto do HAL? Hint - vypište si funkce exportované HAL.dll a kolik z nich se nejmenuje HalNeco? Podstatná je ale nakonec praxe - Win podporují dvě platformy a typicky se na nich stejně používá jen jeden HAL (HalApic) zatímco Linux jich podporuje desítky.

    Thready jsou Windows řešení toho, že spuštění nového procesu pod Win je velice pomalé. Linux tímto problémem netrpí, takže použití threadů není ve většině případů potřeba. A mimochodem implementace v Linuxu umožňuje velice zajímavé věci - viz man clone. Realita ale je taková, že to nikdo příliš nepoužívá protože to je Linux specialita a programy se většinou píší přenositelně. A kupodivu to na jejich rychlosti nějak není znát a jsou s Win docela dobře konkurenceschopné.

    GDI umí nakreslit čáru, kruh, křivku. X11 umí nakreslit čáru, kruh, křivku. GDI komunikuje s drivery. X11 komunikuje s drivery. Stále nějak nevidím ten rozdíl. Možná byste měl doplnit své vzdělání :-)

    Asynchronní IO opravdu Linux umí docela pěkně. Ale opět - programy se píší přenositelně a tak se to moc nepoužívá. Ale opět - zdá se, že to na výkonu není nijak kriticky znát.

    Ono je hezké rozumět všem MS zkratkám. Ale pokud chcete kritizovat Linux, možná by bylo vhodné věnovat trochu času i jeho studiu, nebudete pak tady za /censored/.
  • 29. 12. 2006 16:37

    K2 (neregistrovaný)
    Ad HAL - v jiném příspěvku naopak tvrdíte, že implementace je "zamrzlá". Tady je vidět, že se časem vyvíjí. Jinak HALů se používá více, třeba pro SMP nad 2 CPU.

    Portabilita NT je nesporná. Viz dříve podporované platformy (Alpha, MIPS, PowerPC, SPARC). Rozdíl je v tom "podporovaná platforma". V případě Linuxu to znamená, že někdo na dané architektuře přeložil kernel, a zabootoval. Neřeší se stabilita, výkon, dostupnost SW. Člověk se tak často dozví věci typu že Linux "běží" na 64-cestném SMP - tedy "bootuje", a otázkou výkonu se ani nikdo nezabýval. U MS se jedná o opravdu podporované platformy. No a tady přichází kámen úrazu. Na co více platforem? Prodá se pro ně SW? Danou platformu je nutné udržovat, rozvíjet, podporovat (stylem "bootuje to" to opravdu nestačí). To stojí velké peníze. Zaplatí se to? Zaplatí zákazník 10x dražší workstation s 1,7x vyšším výkonem než na Intelu, když pro ní většina výrobců ani neuvolní SW? Ukázalo se, že nikoliv. Takže MS skončil u x86, x86-64 a IA64. Linux sice "běží" na desítkách platforem, ale na x86 desktopu se pořád pohybuje okolo jednoho procenta. Ostatní platformy na tom budou asi ještě hůře. Co potom z toho?

    Ad thready - ty jsou primárně řešením náročnosti context switche, nikoliv náročnosti spuštění procesu (kterou ve Windows nevidím jako špatnou). Protože thread nemá plný kontext (zvláště memory map), je celá věc daleko rychlejší. Při obsluze přicházejících požadavků pak lze používat thread per request, nebo lépe ukládat požadavky jako objekty, a pracovat nad nimi s definovaným počtem worker threadů. Obojí je ovšem daleko lepší, než work processy. Autoři Apache to už vědí (jenom na AIXu se therady plazí tak, že je nepoužívají). Důvodem je "kupodivu" snaha obsloužit velké množství požadavků. Clone je pravda zajímavý, ale problém neřeší.

    GDI umí nakreslit čáru, bod, křivku, bitmapu, vyplnit uzavřenou křivku gradientem, má podporu alfa-kanálu, umí barevné profily zařízení a barevné separace (default module by Linotype Hell AG), umí nahrávat volání GDI do kontejnerů EMF (metafile) a umí je přehrávat na libovolném zařízení. Pracuje s grafickými kartami, tiskárnami, plottery, s RDP driverem (Remote Desktop Protocol), nebo s čímkoliv jiným. X11 umí tak právě zobrazit bod, čáru a bitmapu - na obrazovce. Nemluvě o API. Doporučuji doplnit vzdělání :-)

    Ad Async IO - Ben LaHaise se kasal, že jednoho dne bude Linux kernel interně používat asynchronní I/O. Windows jsou v tomto stádiu 13 let, Linux interně async I/O v podstatě nepoužívá. Nepoužívá se ani v userlandu, přitom třeba pro DB je to důležitá věc.

    Abych si přisadil: příšerností unixů je systém terminálů. Kdo proboha vymyslel systém stovek nekompatibilních sad sekvencí? OK, mohlo se to stát, ale proč to dávno není zrušené a nahrazené něčím lepším (viz Win32 API pro konzoli)? Když chci napsat text ve žluté barvě, tak nejprve lokalizuji soubor s popisem terminálu, ten parsuji, najdu sekvenci, a vypíšu jí na stdout. Příšernost. Nakonec celý tenhle kolotoč řada aplikací ignoruje, a používá vlastní sady sekvencí (viz třeba Midnight Commander). To bylo z hlediska autora aplikace. Z hlediska uživatele: přiloguji se, konfiguruji environment a terminál, až mi začnou chodit šipky i backspace. Samozřejmě pro konkrétní stroj, na jakémkoliv dalším to absolvuji znovu. Pak ale spustím aplikaci typu Oracle sqlplus, nebo Midnight Commander, a šipky a backspace s vysokou pravděpodobností opět nepůjdou. No a nakonec si nechám vypsat nějaký soubor (cat moje.abc), po čemž mi zmizí i kurzor, nebo píšu nesmyslné znaky. Samozřejmě vím proč - ale nechápu, proč se toho unix dávno nezbavil.

    Myslím, že za /censored/ nejsem. Spíš mě udivuje, kolik lidí o Windows nic neví, ale o to hlasitěji to křičí do světa (nejde o vás konkrétně). Těžko zdejší diskutéry nechat v jejich bludu. Linux není technicky pokročilý systém - jde o kopii komerčních unixů, která je koncepčně celkem zastaralá. Ty Windows, na které zde diskutující tak často nadávají kvůli "barvě ikonek", jsou ve skutečnosti technicky mnohem dále. Jen to chce znát fakta.
  • 30. 12. 2006 21:13

    Petr Baláš (neregistrovaný)
    Ad HAL - vše lze rozmrazit jen něco více něco méně snadno. Zrovna HAL má poměrně malou skupinu uživatelů a tak se s ním dá snáze manipulovat. Ale zde jsem mluvil hlavně o tom, že to co bylo původně krásně navrženo je dnes díky přesunům zmatené. V Linuxu by se to přepsalo znova a přehledně, ve Win se musí udržet zpětná kompatibilita což znamená horší udržovatelnost zdrojáků. IMHO je právě toto (už to není udržovatelné a pokud někdo někam sáhne tak se to vysype někde úplně jinde) byl hlavní při vývoji WinVista. A tím netvrdím, že u MS pracují pitomci, právě naopak jsou v tomto MNOHEM lepší než autoři opensource ale ti si včas uvědomili hrozící problém a nenechali to zajít tak daleko.

    Ad portabilita - koukněte se třeba do žebříčků nejvýkonnějších počítačů a je tam Linux (a netvrďte mi, že na těch strojích neběhá nestabilně). Koukněte se na WiFi/ADSL routery - opět tam najdete většinou Linux a opět běhá stabilně. Win byly navrženy portabilně (otázka ale zní, zda tomu tak je i dnes - ono udržovat portabilní kód je těžké) ale pouze v rozsahu počítačů (od embeded po servery). Variabilita Linuxu je ale poněkud jiná liga. A dostupnost zdrojáků zde HODNĚ pomáhá.

    Ad thready - po forku jaksi oba procesy (otec i syn) mají stejnou memory map jen při změnách se rozdělí (copy on write). Windows nemají obdobu forku. Pokud vím, tak thready pro Apache vznikly primárně proto, aby Apache slušně běhal na Win.

    Ad X11 - pokud to berete takto, tak nad X11 musíte doplnit nějaké ty knihovny aby to bylo srovnatelné. Tisk je řešen samostatně. Jsou dobré důvody pro samostatnost ale jsou i dobré důvody proti. Osobně se mi to, že na serveru nemusím mít žádné GUI a přitom mohu tisknout docela zamlouvá.

    Async IO je pěkné ale důvody proč to s ním není tak žhavé jsem psal už minule tak se nebudu opakovat. Jen ještě dodám, že programovat pro Async IO korektně je docela těžké (psal jsem filter driver pro WinNT a žádný med a dokumentace mizerná).

    Ad terminálové sekvence - ty si vymysleli výrobci jednotlivých terminálů. Praktické použití ale zdaleka není taková hrůza - použiji vhodnou knihovnu a progranuji obdobně jako pod DOSem nebo konsole API pod Win. Blbne to snad jen pokud si blbě nastavím svůj typ terminálu (terminál je jeden ale já program přesvědčím že mám jiný).

    Ano, Windows je v mnoha věcech napřed a obsahuje mnoho velice zajímavých technologií. Ale implementace to často zabíjí (viz např. velice zajímavé subsystémy které ale nakonec degradovaly jen do jednoho). Na druhou stranu Linux zdaleka není tak zaostalý jak se jej snažíte vykreslit.

    Ale to že spousta diskutujících se jde jen vykřičet (a to na obou stranách) je bohužel pravda.
  • 31. 12. 2006 17:58

    anonymní
    Ad vývoj - přesuny naštěstí nejsou technicky velký problém. Viz přesunutí GDI do kernel mode v NT 4.0 - aplikace nepoznaly nic, jenom se zlepšil výkon. Dále není pravda, že se ve Windows nepředělává "od základu". Například Windows NT 4.0 měly výrazně odlišnou strukturu driverů. Windows 2000 zavedly drivery sběrnic, které rozhodují, jaké drivery pro zařízení běžící na dané sběrnici se mají zavést. To byla opravdu velká změna. Stejně tak Vista znamená řadu změn. Obecně je třeba plánovat architekturu s trochou rozhledu, a pokud vyvstaly nové požadavky nebo se něco nepovedlo, tak to mezi verzemi změnit. Rozhraní směrem k aplikacím by se měnit nemělo (proto jsou v API ty funkce *Ex, třeba CreateFileEx).

    Udržování zpětné kompatibility samozřejmě stojí úsilí, ovšem ve výsledku jsme schopni na Windows Vista běžet aplikace psané pro Windows 2.0, a to bez jakýchkoliv změn v těch aplikacích. U Linuxu je vše psané pro aktuální verze, a s ničím novějším ani starším to často neběhá. V důsledku se většina SW šíří jako součást daného distra :/. To vede k tomu, že pro Linux je minimum SW mimo součástí distribuce (ve srovnání s Windows). Obecně úspěšně používat SW šířený v binárkách a nekompilovaný pro dané distro (v dané verzi) je dost problém.

    Ad portabilita - nejvýkonnější počítače jsou typicky clustery, a často na Intelu. Wi-Fi routery jsou ale hezký příklad. Windows by v nich šly použít (jde typicky o MIPS, a má dost paměti pro NT kernel), jenže k tomu není žádný důvod. Výrobce potřebuje velmi nízkou cenu, TCP stack, a tím to končí. Takže na Wi-Fi routerech končí Linux, vxWorks apod.

    Ad thready - znám fork. Windows mají obdobu pouze pod Services for Unix. Fork problémy s výkonem neřeší, mimo jiné protože worker processy alokují paměť pro data často na stejné adresy ve svém address space (prostě memory map je jiná u každého cílového procesu). Proč je v Apache podpora threadů nevím, ale používá se na Linuxu i většině dalších unixů. Údajně to bylo nutné pro ošetření serverů s vysokou zátěží.

    Ad X11 - jinými slovy X11 je technologicky oproti GDI velmi zaostalé, dokonce o generace. Ad tisk - samozřejmě je žádoucí, aby bylo možné jedním kódem kreslit po obrazovce i tiskárně :). Je také dobré, když je možné volání použitá pro kreslení na obrazovce schovat do souboru, a ten soubor pak rastrovat jinde (třeba na té tiskárně); viz WMF, EMF. To s X11 půjde velmi těžko. V případě použití knihoven nad X11 je celá vrstva X11 nadbytečná (viz Qt a embedded zařízení). A právě vy jste říkal, že "v Linuxu by se to přepsalo znova a přehledně". Nepřepsalo, protože to chce plánování a rozhled do budoucna. X11 visí v unixech coby historická příšernost, a nikdo nic nepřepisuje. Nejvýše se něco píše nad stávajícími X11 (s výjimkou těch embedded zařízení, kde je X11 mnohdy naprosto neúnosným overheadem).

    GUI na serveru není k tisku potřeba; stačí modul GDI32, a žádné GUI tam být nemusí. Ovšem otázka je, proč na serveru nemít GUI.

    Async IO je dobré pro specifické účely. Pokud píšu DB engine, je to dost zásadní věc. Pokud píšu jednoduché účto nebo Office, je to celkem jedno.

    Ad terminálové sekvence - tato vrstva měla být dávno zrušena, a mělo zbýt jen API. Ano, blbne to - zvláště proto, že všechny aplikace zřejmě nemají stejný způsob určování typu terminálu. A také proto, že aplikace nepoužívají jediný zdroj sekvencí pro daný typ terminálu. Proč stavět další vrstvu nad zastaralé terminály? Proč ani tuhle skoro 40 let starou příšernost nikdo dodnes nepřepsal od základu? Ještě chcete tvrdit, že "v Linuxu by se to přepsalo znova a přehledně"?

    Ad subsystémy - ostatní subsystémy pořád formálně existují. Samozřejmě se časem ukázalo, že Win32 je prostě nejužívanější. POSIX layer (mimochodem ten *není* wrapperem nad Win32) byl z instalace vydělen do Services for Unix ve Win2K, protože ho skoro nikdo nepoužíval. OS/2 subsystem byl odstraněn také ve Win2K, protože OS/2 v mezičase umřela. Architektura zůstala.

    Těší mě, že uznáte, že Windows jsou před unixy v mnoha věcech výrazně napřed. Mnoho čtenářů root.cz totiž tohle neví, nebo nechce vidět.
  • 31. 12. 2006 20:02

    Petr Baláš (neregistrovaný)
    Přesunout kód y usermode do kernelmode může být mnohem menší problém, než jej napsat jinak :-). Rozdíly v driverech mezi WinNT4 a Win2k zas ta velké nejsou. Přibylo PnP ale bylo naroubováno tak nějak z mého pohledu podivně. O kernelmode vím docela dost - programoval jsem pro něj.

    Linux coby jádro problém není, tam je zpětná kompatibilita udržována slušně. Problém je v přibalených (resp. nepřibalených) knihovnách. Často to lze řešit nasypáním knihoven ze starší verze distribuce. Nebo si musí daná aplikace táhnout svoje knihovny. Je to složitější než pod Windows ale zvládat to lze. Ona zas větší rozmanitost má také své nesporné výhody :-)

    Ad X11 - GDI obsahuje širší paletu služeb. Pod X11 se musí přidat další knihovny. Osobně v tom problém nevidím. X11 není nadbytečné protože jinak by si každý toolkit musel implementovat vlastní drivery (zvěrstvo) a programy psané pro různé toolkity by nespolupracovaly resp. by vůbec nešly spolu spustit. Další výhodou je korektní implamentace síťové transparentnosti (program běží na jednom počítači ale zobrazuje se na druhém - to jak je implementován TerminalServer pod Windows je obludný hack).

    Ad GUI na serveru - čím méně toho na serveru běží, tím menší šance, že na to půjde použít nějaký ten exploit a tím více paměti zbyde pro užitečné programy. U Win2k3 serveru jsem si nějak nevšiml možnosti nainstalovat jej bez GUI.

    AsyncIO - Oracle běží pod Linuxem jedna báseň a je to dokonce primárně vyvíjená verze takže to asi nebude tak horké jak se snažíte podsouvat.

    Ad terminálové sekvence - funguje to, programátorovi to nevadí protože i po přepsání by API zůstalo stejné a občas se to hodí při přístupu z/na nějaký ten starší systém. Tak proč do toho rýpat? Přepis by nepřinesl nic užitečného.

    Ad subsystémy - mluvím o tom, že původně byly subsystémy na sobě nezávislé a vpodstatě šlo vyhodit Win32 subsystém a provozovat systém např. jen s Posix subsystémem. To je dnes už minulost a Win32 subsystém je základní a ostatní na něm závisí.
  • 2. 1. 2007 20:26

    K2 (neregistrovaný)
    Musím trochu brzdit, takže jen to podstatné.

    Ad X11 - není pravda, že bez X11 by si každý toolkit musel implementovat drivery. Viz Windows - drivery poskytují dohodnuté rozhraní, a jiným způsobem na grafiku nikdo nesahá. GDI poskytuje vrstvu abstrakce a odstiňuje od HW-specific features. Nad tím mohou být (a jsou) toolkity. Ad Terminal Services - proč obludný hack? GDI místo na driver grafické karty kreslí na driver RDP protokolu.

    Ad AsyncIO - jistě, Oracle běží. S jakým výkonem? Ano, Oracle se vyvíjí na Linuxu - protože je to unix, a stanice jsou levné.

    Ad terminálové sekvence - přepis by přinesl to, že klávesnice bude bez problému běhat v každé aplikaci. Nejen hjkl, ale i šipky, F-klávesy, numerická klávesnice, backspace. Dále by každá aplikace mohla spolehlivě (a téměř bezpracně) pracovat s barevnými atributy, pozicí kurzoru apod.

    Ad subsystémy - vyhodit Win32 nešlo ani tehdy, protože na něm závisela značná část toho, co bylo součástí Windows. Win32 je logicky nejdůležitější (a skoro jediný) subsystém, protože ostatní byly málo používané. OS/2 umřela, POSIX se moc nepoužíval. Navíc (jak jsem asi psal) Win32 volání dost často končí v kernel mode, a je pak jen wrapperem pro kernelové funkce. Dále POSIX subsystem ani dnes není nadstavbou nad Win32. Viz třeba jeho kompletní case sensitivity, kterou Win32 nemá (naopak kernelové API volitelně ano).
  • 6. 1. 2007 23:22

    Petr Baláš (neregistrovaný)
    Ad X11 - pak berte X11 jako vrstvu s ovladači :-). GDI a toolkity tak trochu splývají - proč je toto v GDI a ne až v toolkitu a naopak?

    Ad AsyncIO a Oracle - Linux + Oracle se běžně používají takže se na první pohled zdá, že tato kombinace MÁ dostatečný výkon. Někde ve vaší úvaze je nějaká chyba.

    Ad terminálové sekvence - na první pohled to taky tak funguje. Alespoň jsem na problém zatím nenarazil. Vy ano? Příklady problémů?

    Ad subsystémy - Win32 by vyhodit šlo pokud nebudete používat nic pro pro Win32 subsystém. Pro stanici nemyslitelníé, pro server by to nemuselo být až zas tak nesmysl. Ale mluvím o závislostech jednotlivých subsystémů. A ta dnes je ale dříve nebyla. Case sensibility je podružný detail (a pokud z Win32 budu volat přímo NtXxx funkce tak ho mohu mít taky - ano, slinkovat usermode program tak aby volal přímo NtXxx API kupodivu NENÍ problém jen to málokdo ví).
  • 6. 1. 2007 23:26

    Petr Baláš (neregistrovaný)
    Ještě ad Terminal Serices - podívejte se na implementaci a pochopíte. To se opravdu nedá jinak nazvat. Ještě jednou - mluvím o vlastní implementaci toho, jak WinNT řeší to, že je více paraleně běžících GDI subsystémů a ne o straně kterou vidí programy.
  • 12. 1. 2007 14:12

    olsen (neregistrovaný)
    Ano, je pravda, že na windows se nadává hloupě, stereotypně a z módy, aby člověk ukázal, "jak moc tomu rozumí". Některé mušky ale mají. Předně si myslím, že vzhledem k tomu, z čeho se tyto OS vyvinuly, linux zdědil lepší bezpečnost. Tady je úkol MS - okopírovat. A to neříkám jako urážku.

    P.S. že je Vista špatně natřený OS/X? To Apple je jedna bublina! Všichni chválí, přitom jestli je něco omalovánka... Pořádné windows mají serepetičky povypínané, chtěl ybch vidět, kam by se bez nich poděl Mac...
  • 29. 12. 2006 15:14

    bez přezdívky
    Trošku bych nesouhlasil jen s tim dělením vlákno-proces.
    Jak víme, vlákna mohou být process-managed (např. Win), nebo os-managed (např. Linux .. ikdyž tam je to trošku posunuto do 1. skupiny). Mě osobně vyhovuje linuxoidní přístup, protože umožňuje běh více vláken v ránci jednoho procesu na více procesorech/jádrech bez jakýchkoliv úprav programu. Navíc m velké plus za řízení priorit procesů, které vícevláknovému běhu dávají větší možnosti a rozlet.
  • 30. 12. 2006 21:15

    Petr Baláš (neregistrovaný)
    Eee? I thready ve Win jsou os-managed ale existuje i možnost použít program-managed způsob. I na Win lze manipulovat s prioritami.
  • 30. 12. 2006 21:23

    bez přezdívky
    Tak tady vychazim ze zkusenosti, protoze pod Win pracuji pod managovanymi/interpretovanymi jazyky a nikdy jsem si nevsiml, ze by na 2 procesorech bezela 2 vlakna.. V .NETu (ktery si mimochodem za behu sam pridava dalsi a dalsi vlakna) jsem vzdy mel zatizeny jen 1 procesor.

    Nerikam, ze Win nema. Jen jsem ho nezkoumal, ale pod Linuchem se mi libi ;)
  • 28. 12. 2006 1:10

    rob (neregistrovaný)
    Pred mesicem jsem take podlehl modni vlne a jsem si poridil MacBook Pro. Predtim jsem na notebooku pouzival Gentoo a Win XP. Krom toho, ze MacBook Pro je podle mne super hardware, OSX mi vyhovuje ze vsech systemu nejvic.

    Oproti linuxu je v OS-X jednoduzsi administrace, propracovane UI, vyborna podpora periferii jako jsou tiskarny, vidokamery, fotoaparaty, telefony, dobra integrace Javy, super stabilita a spousta drobnych featurek/vychytavek, ktere potesi a ulechci praci.

    V linuxu je problem zpracovavat/strihat video pres fireware, problemy dela automaticke mountovani, poradne nefunguje synchronizace s PocketPC (windows mobile 5), nejruznejsi problemy se zvukem (nastavovani ALSY), poradne nefunguje skype (nepodporuje video), suspend to ram/disk je nestabilni, fungovalo tak na 80%, opruz s podporou akcelerace 3d (ati drivers) a dalsi drobne vychytavy, ktere ma OS-X dotazene.

    I pres tyto nedostatky, me pro praci vice vyhovoval Linux nez Win-XP.

    Win-XP jsem na notebooku musel kazdou chvili rebootovat, supent/resume take nefungoval na 100%, spatne hospodareni s pameti - 1G RAM (Oracle DB, AppServer + Java IDE a windows se mohly uswapowat..., Gentoo tohle zvladal se stejnou konfiguraci v pohode). Filesystem ext3 mi take subjektivne prisel sviznejsi nez NTFS, coz se projevilo predevsim u buildovani projektu.

    Jelikoz se zivim vyvojem J2EE Web aplikaci, ktere bezi zpravidla na 40 let zaostalych solarisech a linuxech, prostredi OS-X nebo Linuxu se podoba produkcnimu systemu - narozdil od WinXP. Jenom skoda, ze Oracle nepodporuje OS-X pro intel, takhle ho musim provozovat v Ubuntu pod Parallels, coz funguje take dobre.

    Technologie a cela strategie Applu, od okamziku co presel na Intel, podle mne vypadaja velmi perspektivne! Soucasny rust akcie Applu rozhodne neni zadna bublina. Mozna se budete divit .NET ani zadne dalsi aplikace od M$ k nicemu nepotrebuji.
  • 28. 12. 2006 10:46

    Juraj DURECH
    Ad super stabilita. OSX mi dokaze crashnut po vlozeni horsie vylisovaneho DVD. To sa vam v linuxe alebo vo windows nestane. Najskor spadne iba nejaky player, nie vsak cely system. Toto som naposledy videl este vo win95 :)
  • 28. 12. 2006 14:49

    K2 (neregistrovaný)
    Problémem Javy je jednak HW náročnost (aka pomalost), a potom fakt, že se v ní řada věcí nedá napsat. Samozřejmě u J2EE Web aplikací nezáleží na tom, že v Javě nelze napsat CD recorder :), ale ten výkon... Samozřejmě prostředí Windows se Solarisu moc nepodobá (byť se Services for Unix by mohlo). Musím říci, že je tomu většina lidí ráda.

    Růst akcií Apple je způsobený prodeji jejich přehrávačů iPod, které tvoří většinu zisku. Je to jako by největší procento zisků Oracle pocházelo z prodeje autorádií, ale nakonec pokud to funguje.. Naopak Sunu to moc nefunguje, a je trvale ve ztrátě.

    Přeji mnoho štěstí s Javou - já jí vzdal už před lety. Nakonec optimisticky: vývoj v Javě je pořád stejně drahý, tedy pořád nese dost peněz, a to se počítá.
  • 29. 12. 2006 15:27

    bez přezdívky
    Vzdal jste Javu už před lety? A kdy to bylo?
    Java 1.4.2 podle mě nebyl programovací jazyk. Byl pomalý, téměř nepoužitelný.
    Do Javy 1.5 jsem se zamiloval. Má mnoho vychytávek (pravda .. C# má ještě pořád něco navíc, ale mě vyhovuje ta koncepce virtuálních metod - nenastavuj, překryj >:). S rychlostí a HotSpotem (který teď funguje i při překladu klientského kódu) se při některých výpočtech dokáže dostat i nad výkonnost Céčka (důkaz přímo od p. Herouta :)
    A teď přichází 1.6, kde se prý konečně vyřešily problémy s konzolovým vstupem ;)
    Vřele doporučuji vyzkoušet.
  • 29. 12. 2006 17:01

    K2 (neregistrovaný)
    Budu o tom uvažovat. Nevím ale, co bych v Javě psal. Když něco píšu, je to klientská aplikace, nebo Windows service. Psát aplikaci pro nahrávání audia v Javě opravdu nejde :), naopak v C# bez problému. Stejně tak XAML aplikaci budu těžko psát v Javě; přitom XAML bude podle všeho jazykem "intranetu", a asi i webu. V Javě se dá efektivně psát middleware - jenže ten lze psát stejně (a podle mě lépe) i v .NETu, a navíc v něm lze psát i jiné věci.

    S Javou jsem skončil s JDK 1.1.4, resp. o rok později. Například celý ten kolotoč s AWK, SWT a Swing je designová příšernost. Podpora tisku byla katastrofální (resp. žádná), nemluvě o "maličkostech" typu fonty, správa barev, imaging... V posledních verzích Javy jsem zase opakovaně narážel na nevyhovující správu paměti. Java potřebuje souvislý paměťový prostor, což je problém (na x86 to jde nad 1.3GB jen těžko, i když má proces 2.5GB paměti k dispozici). Sun prostě nedostál svým slibům, proto Java efektivně umřela.

    Jako příklad špatného použí Javy a XML ("nový přístup") uvedu DXL. Lotus Notes umí interpretovat třeba emaily pomocí XML (Domino XML Language). Na papíře to vypadá skvěle, čtyři tagy typu "subject", "to", "from", "body". V praxi mají zprávy formátování a přílohy. Exportovaná zpráva potřebuje v Javě (knihovny by IBM) 8x více paměti, než má vlastní mailová zpráva, a tahá se to po síti (síť je pak mrtvá). DXL exporter (by IBM) občas produkuje zprávy, které nejsou DXL validní, tedy je neumí naimportovat (spadne importer). Pokud člověk provede verifikaci, a "divoké" zprávy vyhází, stejně občas zbyde nějaká, kterou Notes nesežerou, a thread se při importu kousne. Celé je to nesmírně paměťově náročné, pomalé jako slimák, a pohodlné jako bodláky v trenkách. To byla moje zkušenost s Javou a IBM Domino před rokem. Uznávám, že Java za to může méně než IBM, ale ty hloupé limity (třeba správa paměti) opravdu nepotěší; stejně tak výkon nic moc.
  • 30. 12. 2006 15:26

    Miloslav Ponkrác
    Proboha, kde jste vzal tu hovadinu, že Java se může dostat nad výkonnost Céčka? Pokud někdo tento důkaz potvrdil, tak je blb, a to bez ohledu nad to jaká autorita to je.

    Zajímavé je, že tyto kraviny se objevují pořád dokola, ale nikdo to nikdy nedokázal žádným SERIÓZNÍM testem. Sám jsem prošel dost testů, které to údajně měly dokazovat a ve všech jsem objevil tak závažné chyby, že to až bolelo.

    Takže prosím o důkaz.

    Jinak pane mirousek, těch nepřesností máte více. Například napsat, že ve Vista nebude Win32 API. Obávám se, že informace od Vás budu brát do kolonky "nevěrohodné - nutno ověřit jinde, případně rovnou nebrat v úvahu".
  • 30. 12. 2006 18:13

    bez přezdívky
    Potvrdil to jednoduchym prikladem. Slo o vypocet .. priznam se, ze uz nevim ceho..

    Pravda je, jsem zkousel vypocet e v Jave 1.4.1. Scitanim zlomku. Docela me preklvapilo, ze prime vydeleni zlomku a pricteni k predchazejicimu kusu rady (tedy pocitani temer ciste ve floatu) trvalo stejne dlouho jako pocitani celych cisel (nasobeni citatelu z predchozi casti rady a pricteni dalsiho) s jednim jedinym delenim na konci (ano, pouzival jsem int a ne cela cisla ulozena ve floatu:).

    HotSpot dokaze hodne. Kompilator Cecka sice dokaze kod zoptimalizovat lepe, nez to dokaze lecktery ASM programator. Zvlaste je-li algoritmus delsi a neprehlednejsi. Nedokaze ale predpovedet skutecne vyuziti kodu. To Java dokaze. Pred spustenim programu se cast kodu 'zkompiluje' (sice tenhle termin asi nebude znamenat kompilaci jako takovou, ale Java ho pouziva) a zbytek interpretuje. Za behu vyuziva profiler, na jehoz zaklade je schopna program za behu prestavet a casti, ktere se uz jevi jako optimalizovane 'zkompiluje'. Diky tomu muze optimalizovat vice vytizene casti kodu na ukor mene vytizenych.

    Kde tu vidite nejaky duvod, proc by nemohla Java byt v nekterych situacich rychlejsi?

    Prvni provedeni metody vetsinou trva dlouho. Ale uz treti ctvrty beh dava casto velmi zajimave vysledky.

    Dukaz mohu dat az budu mit trosku casu = po zkouskovem. Ted musim dodelat jednu semestralku v Jave a pujdu na dalsi v C :)

    Ale tak informace ode me jsou vlastne neverohodne.. no nic.. treba na to nekdo jiny skoci. Po nicem jinem netouzim, nez mystifikovat okoli >:)

    ---
    Kde jsem vzal tu informaci o Win32API, to jste cetl. Vcetne me omluvy. Asi nemam, co bych dodal..
  • 30. 12. 2006 19:25

    Miloslav Ponkrác_ (neregistrovaný)
    Hlavním důvodem je to, že nikdo to ještě prakticky nepředvedl. Prošel jsem dostupné testy, kde to nikdo tvrdí a vždy jsem přišel na to, že test jen dokázal, že někdo neumí psát v C/C++. Napsal jsem dokonce o tom i souhrnný článek.

    C kompilátor dokáže optimalizovat lépe, než leckterý asm kompilátor, ale špičkový assemblerista položí i nejlepší C kompilátor na lopatky. Problém je, že složitost C a ASM je taková, že je to v ASM o několik řádů složitější. Rozdíl mezi C/C++ a Javou je v podstatě zanedbatelný co se týká složitosti zápisů a nedá se s rozdílem mezi C a ASM ani vzdáleně srovnávat.

    Když ale jsme u té teorie, problém je, že veškeré optimalizace a profilování se provádí na rozdíl od C u Javy za běhu a tato režie dále zpomaluje běh Javy. Pokud je program v C/C++ dobře napsaný, Java se prostě nechytá a ani náhodou nebude rychlejší. A to ani nemluvím o tom, že navíc program v C/C++ bude rychleji startovat, sežere zlomeček paměti a mnohem méně dalších zdrojů systému oproti Javě.

    Ale nechme teorii, zkusme praxi. Předložte jediný důkaz, kde Java je rychlejší, než C/C++. Tento důkaz totiž zatím nikdo na světě nepředložil. Takže shrnuto: teze o Javě rychlejší, než C/C++ jsou bohapustou lží, kterou nikdo na světě nepodložil něčím konkrétním a seriózním.

    Až bude Java rychlejší, pak mi věřte, že týmy vědců, které programují rychlostně kritické algoritmy nebudou programovat v C/C++, ale vrhnou se na Javu, neboť i necelé procento zrychlení by je zajímalo. Ale že se tak neděje a vše rychlostně kritické se stále píše v C/C++/asm je důkazem, že tvrzení o Javě je jen ničím nepodložený žvást.

    Navíc i Microsoft, který umí udělat jak rychlejší JVM, než Sun, jak prakticky dokázal, než mu Sun jeho JVM zakázal používat, tak i o trošičku rychlejší .NET framework na rovinu píše, že C++ je rychlejší.
  • 30. 12. 2006 19:39

    bez přezdívky
    Samozrejme. Rychlost programu je ASM > C > C++ > Java/C#. Jinak tomu ani byt nemuze a matematicky neni slozite to dokazat. Jestlize stravim nad slozitejsi funkci dost hodin s profilerem a implementacnim materialem toho urciteho procesoru, pro ktery prave pisi, udelam v ASM rychlejsi program nez v C. Poradny kus tehle prace ale za me udelali vyvojari C. Stejne tak teprve kdyz nad slozitejsi Ceckovskou funkci stravim tyden s profilerem, mohu zodpovedne rict, ze zadny jiny prekladac (Java, ...) nedokaze vytvorit efektivnejsi kod ani za pomoci on-line profileru. A vetsinou tomu tak bude. Ted jde o to, jestli mam ty tydny casu na prechod Java=>C=>ASM a jestli to stoji za to. Protoze v pripade, ze to neudelam, je tu docela realna moznost, ze Ceckovsky prekladac vytvori efektivnejsi program nez ja (v 300 instrukci se snadno udela nejaka zbytecna operace). Stejne tak C<->Java.
  • 30. 12. 2006 20:12

    Miloslav Ponkrác_ (neregistrovaný)
    Dovolím si opravit: Rychlost programu je reálně takto: ASM > C = C++ > C# > Java.

    Přechod mezi Java a C a zejména C++ není nijak náročný, proto jsem psal, že mají podobnou složitost. Pokud budu vědět, že mám v C/C++ psát program, kde záleží na rychlost, nepotřebuji ani profiler, abych rychlostně trumfnul Javu. Ono je to totiž proto že C/C++ vznilky proto, aby se mohly psát vysoce efektivní programy a maximálně rychlé a skoro vše je tomu v těch jazycích podřízeno. Přitom zejména C++ je poměrně vysokoúrovňový jazyk.

    Souhlasím s tím, že prochod C => ASM se téměř nikdy nevyplatí, protože složitost ASM je velmi značná oproti C/C++. Ale přechod Java => C++ není nija k náročný, pokud umíte oba jazyky a pokud záleží na rychlosti, rozhodně se časově i ekonomicky víc, než vyplatí.

    Celý problém je v tom, že prostě Java má zůstat tam kde je a nerozšiřovat lži ve stylu, že je rychlejší, než C/C++, protože tohle prostě Javě do vínku dáno nebylo a nikdy nebude. Stejně tak jako Java nikdy nebyla a nebude neobjektovějším jazykem, ani nejbezpečnějším jazykem.
  • 30. 12. 2006 20:32

    bez přezdívky
    Jestlize pouzivate C++, pak pouzivate mj. i objekty. To kod zprehlednuje, ale zpomaluje. Takze podle me je C > C++.

    K C# vs. Java.. Zkopiruji svuj prispevek od jineho clanku:

    --
    Tyden stary pribeh: vytvoril jsem program v .NET2.0, ktery nacita jednotlive vety z databaze, prozene je XSL transformaci a ulozi zpet do jedne bunky. Na lokalnim pocitaci (1.6GHz, 1G RAM) se spusti, pracuje, na pozadani skonci. Pustim ho na serveru (4x1.5GHz, 4G RAM - 1G RAM volne). Okamzite po nacteni XSL sablony zacne jeji kompilace, behem 4 vterin si sezere temer presne 500M RAM a 10min. se nic nedeje (az na 100% vytizeni jednoho z procesoru). Pak se umoudri, vyuzita pamet spadne na 60-80M a zacne pracovat jako by se nic nestalo.
    --

    Takovehle excesy jsem s Javou jeste nezazil.

    Dalsim pripadem je to, ze v C# jsem narazil na problem, kdy byl silene pomaly pri rekurzivnim prochazeni stromem. Ten strom nemel nijak slozitou strukturu uzlu, dcerinne uzly byly kolekce a vypnuti vsech operaci nad uzly (zustalo jen samotne prochazeni) znamenalo narust vykonu o nejakych slabych 10%.

    Ke svemu prekvapeni jsem zjistil i to, ze server-side generovane stranky v JSP na Tomcatu jsou generovane svizneji nez v ASP na IIS. A ze Tomcat rozhodne nepatri mezi nejrychlejsi servery.


    Ano. Souhlasim, ze ve vetsine pripadu je C# rychlejsi. Ale kdyz uz neni, tak je ten rozdil vetsinou docela markantni.
  • 30. 12. 2006 22:38

    Miloslav Ponkrác
    Pokud používám objekty, automaticky to neznamená zpomalení. Takže C = C++. Nehledě vůbec na to, že C++ nijak nepředepisuje, že se musí používat objekty, C++ to nevyžaduje, takže znovu C = C++. Neexistuje jediný důvod ani jediný případ, kdy by nešlo v C++ napsat stejně rychlý program jako v C.

    K C# versus Java - nechci to tu rozebírat, prostě všechny ty dynamické optimalizace, které jste uvedl mohou zpomalit a zrychlit. Je mi to buřt a nemám žádné ambice se pouštět do debat, kde z principu vím, že běhové mašiny dynamických jazyků již z podstaty se takto mohou zachovat. To, že jste to neobjevil u Javy neznamená, že to tak není. Ale toto téma rozvíjet nebudu, poněvadž mi je to jedno.
  • 28. 12. 2006 7:52

    anonymní
    Co porad mate s tin .NET frameworkem? Co je na nem tak zazracnyho? A myslite, ze by neco takoveho vzniklo, kdyby s tim neprisel SUN jako prvni (java) ?
  • 28. 12. 2006 10:24

    anonymous (neregistrovaný)
    těžko říct, asi ano. A podívej na výsledek, jak se .net rozjel v době, když tady Java byla.

    To samozřejmě platilo až do chvíle, kdy SUN ohlásil převedení javy na GPL, což je podle mne pro Microsoft nejhorší zpráva za posledních 5 let. Opravdu se teď strašně těším na to, až budu sledovat co komunita s Javou dokáže, a kam ji posune. Pro začátek se třeba i podaří z Linuxu (potažmo GNOME) odstranit i Mono...
  • 28. 12. 2006 15:05

    K2 (neregistrovaný)
    Java na začátku slibovala v úžasném hype vyřešení probémů IT světa. Měli jsme mít všichni JavaStations s Javou místo OS, a HDD používat jen na cachování appletů. Jenže zatím co média šílela, já jsem po počátečním nadšení velmi smutně zjišťoval, že tehdejší Java neměla ani pořádnou podporu formulářů. Nebylo možné tisknout, zacházet s barvami, vybírat fonty. Neexistovaly .jar balíčky, takže větší projekt skončil v hrozném klubku maličkých souborů. Hřebíkem do rakve byl pokus zvaný Corel Office for Java, který celkem hezky ukazoval technické limity tehdejší Javy. Neskutečně pomalá věc (což pravda na mega-drahém HW od Sunu nebyl až takový problém), hrozivě nevzhledný user interface, absence fontů, tisku, velikost cca 80MB, funkčnost WordPadu (jen pořád chyběly ty funty). Corel vývoj zastavil, já po vlastních pokusech s Javou skončil. Není bez zajímavosti, že Java byla původně určena pro zařízení typu diáře, mikrovlnky apod. Nebudete psát firmware - přeložíte Java Virtual Machine pro cílovou architekturu, a použijete firmware v Javě. Nepovedlo se, nikdo to tak nedělá ("díky" problémům s výkonem). Java na desktopu to také neustála (za což si Sun může dost sám ne-dohodou s MS), applety jsou dnes okrajové. Nakonec Java utekla na stranu serveru, kde spokojeně stagnuje. Nyní ji Sun uvolnil jako open source, což znamená, že z Javy už moc peněz nezíská. Sun měl odjakživa problém prodat své produkty a dosáhnout zisku. Viz fakt, že je trvale ve ztrátě. McNealy každým rokem slibuje, že budou profitovat, a pořád to nejde. Faktem je, že uvolnění Javy nebude Sun stát příliš příjmů, protože z Javy žádné pořádné příjmy nikdy neměl.

    .NET je dobře optimalizovaný, a tedy rychlejší než Java. Na rozdíl od Javy používá objekty operačního systému, takže look and feel .NET aplikace je naproto běžný, "Windowsový". V .NETu lze použít Managed DirectX, COM objekty, .NET komponenty lze naopak použít z COM prostředí. Lze volat nativní metody. Avalon je super věc, díky které bude možné psát webové aplikace s interfacem běžných okenních aplikací (sbohem příšernému webovému interface).

    Kam posune komunita Javu? To záleží na tom, kdo bude "komunitu" platit. Sun nyní platí vývoj "komunitního" OpenOffice. Vývoj leze dopředu, ale na špičku zdaleka nestačí. Příjmy z OpenOffice/StarOffice jsou prakticky nulové, Sun na celé věci jen prodělává. Jestli to bude podobné s Javou, tak je na čase se loučit s legendou jménem Sun.
  • 29. 12. 2006 15:32

    bez přezdívky
    Jak jsem psal výše - Java se probudila.
    Bohužel, máte pravdu, že Sun neumí prodávat. Nakonec.. produkty mimo Javy jako takové jsou často tragické. Zkoušel někdy někdo z Vás JavaMediaFramework? Jestli chcete zažít horror, pošlu Vám svoji přípravu na bakalářku i s barvitým komentářem ;)
  • 28. 12. 2006 15:13

    K2 (neregistrovaný)
    K Mono bych řekl, že je v zájmu Linuxu mít prostředí pro běh .NET aplikací. Ty totiž na trhu budou stejně běžné, jako dnes Win32 aplikace. Samozřejmě pokud nemáte zájem mít aplikace pro Linux, odstřelte Mono. Mimochodem se pak bude i blbě brouzdat po webu, až velké procento stránek bude v XAML, a bude nabízet interface běžné okenní aplikace přes web.
  • 29. 12. 2006 15:35

    bez přezdívky
    Přesně tak. Mono není třeba odstřelit, ale podpořit. Btw. víte o RoToru? Byla to implementace .NETu pro Linux made by M$. Bohužel, bylo to free a dost by to posílilo pozici Linuxu a přenositelnost programů, tak se dál nevyvíjí.
  • 29. 12. 2006 17:18

    K2 (neregistrovaný)
    Těžko po MS chtít, aby cíleně oslaboval svoji pozici na trhu. Faktem ale je, že Rotor 2.0 je k dispozici (pro Windows).

    Další problém je v tom, že MS měl co dělat s vydáním Windows MCE (v USA velmi úspěšné), Windows pro TabletPC, Visty, a teď se chystá na Longhorn Server. Teď už je nepatrně volněji, ale okolo Visty bylo fakt husto. Uvolňování zdrojáků .NET Frameworku řekněme nebylo prioritou. Uvidíme, jestli se dotyční rozhoupou něco udělat okolo .NETu 3.0, až budou mít kdy. Možná to bude v zájmu MS, pokud bude chtít z XAML udělat jazyk webu (na 100% chtít bude, na 90% se mu to povede).
  • 30. 12. 2006 21:20

    Petr Baláš (neregistrovaný)
    Možný průser je v tom, že se rozšíří Mono, pak MS přijde s nějakým pěkným patentem a Mono odstřelí a lidem nezbyde nic jiného než se pokorně vrátit k Windows. A to je to, oč tu kráčí.
  • 29. 12. 2006 15:07

    bez přezdívky
    Win32 - tím myslíš to šílené Win32API? 10 let staré dědictví, které plácali jak vlaštovky a vršili čím dál tím víc marastu z důvodu zachování zpštné kompatibility, která stejně vpodstatě neexistuje? Ještě že Win32API už ve Vistách není. To je jejich plus ;)
  • 29. 12. 2006 15:33

    K2 (neregistrovaný)
    Win32 není ve Vistě? To je novinka - pro mě, pro MS, pro každého. Skoro by to chtělo si o věci něco přečíst...
  • 29. 12. 2006 15:38

    bez přezdívky
    Jestli je, tak to se omlouvám. A jestli víte o nějakém zajímavém linku, rád si ho přeštu.
    Vycházím z toho, co jsem před víc jak rokem slyšel přímo od zdroje na MS Developer Days..
  • 29. 12. 2006 17:13

    K2 (neregistrovaný)
    Vista má nadále Win32 API. Pánové zřejmě upozorňovali primárně na to, že pro MS končí veškeré frameworky typu MFC, VBRUN a další, a nahrazuje je pouze .NET.

    Postupem času se zřejmě počítá s odchodem Win32. Možná už příští verze Windows bude Win32 provádět v nějakém sandboxu. Ovšem to zatím těžko soudit - viz Windows 95, které měly být přechodem mezi Windows 3.x a Windows NT. Nakonec přechod na řadu NT nastal po 7 letech. Osobně bych psal nové věci v .NETu. Staré bych nechal dožít; ohladuji že mají minimálně 10-15 let času, než Win32 umře úplně.
  • 30. 12. 2006 22:46

    Miloslav Ponkrác
    Windows (jakékoli jeho příští verze) bude mít vždycky Win32 API jako základ a cokoli jiného bude nad tím. Včetně celého .NET. Možná to nebude Win32 API, možná to bude Win64 API, nebo Win128 API, ale nikdy to nebude jinak.
  • 31. 12. 2006 16:53

    anonymní
    Dovoluji si vám připomenout, že velká část Win32 volání se ve skutečnosti provádí na úrovni kernelu (příslušná knihovna typu GDI32.dll provede syscall). .NET může s klidem používat právě tyto kernelové funkce. Win32 tak jak ho známe je jen jeden z modulů. MS samozřejmě bude držet kompatibilitu, ale otázka je, kolik nových věcí půjde napsat jen v .NETu. Win32 bude existovat primárně z důvodu zpětné kompatibility, a za mnoho let dopadne stejně, jako VDM (Virtual DOS Machine) v 64-bit Windows. Je to samozřejmě spekulace; tak daleko dopředu nevidí ani autoři Windows. Faktem je, že MS interně diskutoval oddělení (možná některého) unmnaged kódu do sandboxu, s tím že koupě VirtualPC měla přinést potřebné technologie. Rozhodně to ale není věc, která by měla nastat zítra ;)
  • 31. 12. 2006 19:32

    Miloslav Ponkrác
    Jasně, a všechno se bude na všech procesorových platformách (i těch co nedisponují syscallem) a ve všech verzích Windows volat pomocí kernel mode věci. Nehledě na to, že používat v mnoha programech kernel mode interface je značně (zejména ekonomicky) nepraktické už kvůli větší proměnlivosti tohoto rozhraní.

    Win API bude vždy pro user mode věci základ a ve Win API bude vždy nadřazeno jakémukoli jinému rozhraní. I v .NETu půjde udělat pouze podmnožina toho, co lze udělat ve Win API. Je sice teoreticky možné, že Win API bude pouze emulováno, ale je to tak nepravděpodobné, že to neberu ani moc v úvahu pokud se bavíme o Windows samotných.

    Mimochodem v Unixem je to stejně, také existuje kernel mode rozhraní, ale ještě nikdo nevypouští podobné debility ve stylu, že hlavní rozhraní bude Java a mnoho nových věcí v Linuxu půjde napsat jen v Javě, ale v ničem jiném, abych napsal něco analogického. A přitom je to naprosto stejná hovadina jako s tím, že nové věci půjdou ve Windows jen v .NETu. Prosím přestaňte už s těmi bláboly o .NETu. Nepleťte si skutečnost s marketinkovými kecy, které napíše nějaký senzacechtivý novinář, nebo blogger.
  • 2. 1. 2007 20:43

    K2 (neregistrovaný)
    Budeme trochu brzdit ohledně výraziva, OK?

    Netvrdil jsem, že se bude nezbyteně používat kernel-mode interface. Tvrdil jsem, že v MS probíhaly diskuze na téma sandboxování Win32 kódu. V případě managed kódu (.NET) lze totiž celkem přesně říci, co daný proces smí, a co ne. V případě unmanaged kódu (Win32) není problém pro program joke32.exe naslouchat na portech, přistupovat k disku; může dělat v podstatě cokoliv, co dovolí kontext uživatele. Nikdo není schopen říci, co z toho to bude.

    Je pravděpodobné, že nové věci ve Windows půjdou výrazně jednodušeji napsat v .NETu. Nakonec můžete psát pomocí kernel API, nebo Win32, ale bude to výrazně pracnější. .NET se stává primární platformou.
  • 2. 1. 2007 21:02

    K2 (neregistrovaný)
    Ještě jsem vás chtěl upozornit na projekt Singularity:
    http://research.microsoft.com/os/singularity/

    Jde o experimentální OS, napsaný převážně v C#. Procesy běží v ring 0, a jsou oddělené pomocí features Common Intermediate Language. Při instalaci/kompilaci kódu (CIL do nativního kódu) se zkontroluje, zda naplňuje dané podmínky (nehrabe kam nemá). Jde o významný odklon od HW řešeného oddělení procesů, které zavedl Multics, a který dnes používá v podstatě každý. Oddělení procesů je v Singularity tak nenáročné na zdroje, že to velmi překvapí. Samozřejmě managed code je pomalejší, ale ve výsledku je díky "levnému" oddělení procesů rychlost podobná, jako u "tradičních" systémů.

    Umíte si představit, že MS vydá Windows založené na Singularity, a Win32 kód bude běžet v emulaci? Zatím určitě ne, ale za 8-12 let klidně ano. Tolik k .NETu, resp. CIL.
  • 2. 1. 2007 21:13

    bez přezdívky
    To je rozhodne zajimava informace :)
    Jen se bojim, aby z toho ve vysledku nebyl jen jeden velky sandbox (neco ve stylu spravcu virtualnich stroju).
  • 2. 1. 2007 22:00

    Miloslav Ponkrác_ (neregistrovaný)
    Myslíte tu úžasnou novinu, která už desítky let před MS fungovala (a na rozdíl od MS dokonce v praxi, ne experimentálně)? Myslím, že LISP mašiny bylo přesně to samé.

    Už vidím, jak na x86 procesoru poběží Singularity a nad ním emulátor x86 procesů běžící v IL. :-)
  • 3. 1. 2007 1:17

    K2 (neregistrovaný)
    Inferno, Plan 9, Genera - pokusů bylo víc. Žádný z nich nebyl "přesně to samé", co Singularity.

    Jste si jistý, že za 8-12 let tu budeme mít x86 procesory, které vychází z 80386 (rok 1986)? A říká vám něco Moore's Law? Pokud výpočetní výkon poroste jako dosud, nebude s emulací x86 v IL výrazný problém. Samozřejmě je to zatím čistá spekulace.
  • 3. 1. 2007 1:46

    Miloslav Ponkrác
    Jenže to nebyly vždy pokusy, třeba Plan 9 je v praxi docela používán alepoň tam kde ho vyvinuli. Navíc Plan 9 není nic, než operační systém, pod kterým běží věci ve strojáku.

    Takže srovnáváte nesrovnatelné. Singularity není v zásadě operační systém, ač je tak neprávem vznostně nazýván, je to jen jedna velká virtuální mašina pro .NET programy. Nic víc a nic míň. Navíc má Singularity určitá dost hnusná omezení, které jste tu ze skromnosti zamlčel.

    Nejsem si jistý ničím, ale na rozdíl od Vás neříkám, že tu příštích milión let všechno ovládne .NET, ani netvrdím, že je .NET pupek světa. .NET není až tak nic vyjímečného, co tu několikrát předtím nebylo. Jinak Moore's Law se absolutně netýká toho jaké procesory tu budou.
  • 3. 1. 2007 5:08

    K2 (neregistrovaný)
    Plan 9 se nikdy významně nerozšířil, a Lucent opustil plány na komerční využití.

    Singularity je opravdu "jedna velká virtuální mašina". To neznamená, že to není operační systém. Nakonec o unixech můžete tvrdit, že je to jeden velký C runtime, a nikoliv operační systém. O C runtime s trochou nadsázky jde (viz "jedna velká virtuální mašina"), ale OS to je.

    .NET je samozřejmě jen technologie. Ale je třeba vzít v úvahu, že zatím co LISP Machines se (údajně) v nejlepších letech prodalo až 7000 ks za rok, Windows se svým .NET runtime jsou na cca 200 mln počítačích.

    Ohledně sandboxingu Win32 aplikací jsem dohledal link na Wikipedii, kde se tento přístup zmiňuje v souvislosti s příští verzí Windows. Veškerý non-managed (tj. mimo jiné Win32) kód má údajně běžet v sandboxu:
    http://en.wikipedia.org/wiki/Windows_Vienna#Other_features

    Co na to řeknete teď? Že jsem to na Wiki napsal já? ;)
  • 3. 1. 2007 9:37

    Miloslav Ponkrac (neregistrovaný)
    Nikdo tu nemluvil o významném rozšíření, Plan 9 je nicméně reálný použitelný systém na rozdíl od Singularity a můžete ho klidně používat i Vy. To je rozdíl od opravdového operačního systému, kterým Plan9 je od Singularity, který kromě toho, že se o něm píše a slouží jako reklama Microsoftu je k ničemu.

    Unix není jeden velký C runtime, neboť zvládá spustit nativní binárky a nemusí nic emulovat. Ta nativní binárka nemusela mít s C nic společného.

    LISP MAchines se prodalo 7000 ks za rok v době, kdy to procentuálně znamenalo obrovské množství počítačů. Zatímco Singularity se nikdy neprodalo ani kus a pravděpodobně ani neprodá, neboť to má takové vlastnosti a omezení, že je to v reálu nepoužitelné a mimo brány výzkumného ústavu je to nanic, kromě toho, že to někdo vydává mylně za operační systém. Máte zázračnou vlastnost srovnávat nesrovnatelné, Windows + .NET runtime není Singularity, takže vaše srovnání s Plan9 je značně, ale značně neseriózní.

    Jinak ohledně sandboxingu to jako mění co? Na tom není nic nenormálního. Ono je tak nějak normální, že operační systém omezuje procesy od toho tam je.

    Jinak co se týká příští verze Windows, a co má běžet kde řeknu jen to, že si přečtěte, co všechno bylo naslibováno, že má být ve Vistě a jestli tam toho je třetina z toho tak je to moc. Nakecat jde všechno. Nakonec byl MS rád, když dokázal implementovat do Visty alespoň zlomek z toho co slíbil a musel neustále odvolávat, že toto tam nebude a toto tam nebude. Takže různá provolání mě nechávají chladným.
  • 3. 1. 2007 16:37

    K2 (neregistrovaný)
    Singularity není reklama, ale research project, na kterém se vymýšlejí a testují technologie.

    Unix zvládá "nativní binárky"? A co ty binárky dělají? Volají C API, protože unix má jako jediné "oficiální" rozhraní libc. Vyšší jazyky mají mnohdy runtime knihovny, které toto C API obalují. Samozřejmě lze psát v ASM, ale o tom asi nemluvíte. Singularity běží CIL, tedy C#, J#, Managed C++, Visual Basic, Python.NET. Samozřejmě lze psát i v CIL jakožto "objektovém assembleru", ale opět to není to pravé. Tj. Singularity je OS, stejně jako Unix. Nakonec se podívejte na definici OS: http://en.wikipedia.org/wiki/Operating_system

    Ad LISP machine - v roce 1988 (o kterém mluvím) se údajně prodalo až 7000 LISP machines. IBM klony byly čerstvě vybaveny VGA displayem, masivně se používaly DBase a FoxPro. Na Macu jsou Claris Works, Microsoft Word a Microsoft Excel. Opravdu si myslíte, že těch 7000 LISP machines bylo "významné procento" prodaných počítačů?

    Ad Win + .NET není Singularity - není. Ad sandboxing - Win32 kód je samozřejmě i dnes omezený v tom, co může. Máme permissions (ACL na "všem co se hýbe"), priviledges (eject removable media: power users, admins). Nicméně Win32 kód smí vše, co smí uživatel, v jehož kontextu kód běží.

    Popisuji tu, že v době uvedení příští verze Windows bude .NET zřejmě primárním API. Přes Win32 se některé věci budou dělat velmi přes ruku, a nakonec asi poběží v sandboxu (než definitivně umře). C++ se bude používat v managed módu. Doložil jsem to linky. Více k tomu těžko říci...
  • 3. 1. 2007 18:33

    Miloslav Ponkrác_ (neregistrovaný)
    ...........Singularity není reklama, ale research project, na kterém se vymýšlejí a testují technologie.

    Ok, ale pro MS to není reklama, že ne?

    ............Unix zvládá "nativní binárky"?

    Který unix?

    ............A co ty binárky dělají? Volají C API, protože unix má jako jediné "oficiální" rozhraní libc.

    Unix je moc široký pojem. Nicméně to co tam běží není C zdroják, ale stroják. V binárce obvykle nenajdete ani stopu po C zdrojovém kódu.

    ..........Singularity běží CIL, tedy C#, J#, Managed C++, Visual Basic, Python.NET.

    Ne, na Singularity běží CIL. Tečka. Jakým způsobem se dosáhne tohoto tvaru je nepodstatné pro Singularity.

    Tj. Singularity je OS, stejně jako Unix. Nakonec se podívejte na definici OS: http://en.wikipedia.org/wiki/Operating_system

    Singularity je pouze virtuální mašina. Lze ji vznostně nazývat operačním systémem, ale jeho schopnosti jsou dost při zemi.

    .................."Ad LISP machine - v roce 1988 (o kterém mluvím) se údajně prodalo až 7000 LISP machines. IBM klony byly čerstvě vybaveny VGA displayem, masivně se používaly DBase a FoxPro. Na Macu jsou Claris Works, Microsoft Word a Microsoft Excel. Opravdu si myslíte, že těch 7000 LISP machines bylo "významné procento" prodaných počítačů?"

    Pořád je to víc počítačů, než na jakém do této chvíle kdy běžel Singularity. :-) Ono to totiž opravdu v reále běželo a nebyly to jen sliby, kecy, ehm pardon prakticky nepoužitelný research projekt.

    ................Nicméně Win32 kód smí vše, co smí uživatel, v jehož kontextu kód běží.

    Win32 smí vše co mu systém dovolí. Nic víc a nic míň.

    ...............Popisuji tu, že v době uvedení příští verze Windows bude .NET zřejmě primárním API. Přes Win32 se některé věci budou dělat velmi přes ruku, a nakonec asi poběží v sandboxu (než definitivně umře). C++ se bude používat v managed módu. Doložil jsem to linky. Více k tomu těžko říci...

    Aha, tak Vy linky dokládáte budoucnost. :-). Já zase doložil prakticky co všechno mělo být oficiálně ve Windows Vista a můžete se podívat co tam skutečně je. Jak MS škrtal a škrtal a škrtal.
  • 3. 1. 2007 20:16

    K2 (neregistrovaný)
    Jestli Singularity je nebo není reklama, to nebudu soudit, a nepřipadá mi to relevantní.

    Unix je jeden, uměle rozbitý do různých navzájem mizerně kompatibilních produktů.

    Na Singularity samozřejmě běží také stroják. CIL se přeloží do strojáku, a ten se pak pouští. Při překladu z CIL do strojáku se zjišťuje, zda kód vyhovuje kritériím. U výsledného strojáku už nemá smysl mluvit o virtual machine.

    Ad Win32 smí vše co mu systém dovolí - to jistě ano :). Nicméně trochu pomíjíte rozdíl mezi současným stavem (Win32 sandboxing existuje, ale má omezení), a mezi řekněme během Win32 aplikací na virtuálních strojích.

    Ad budoucnost - já dokládám, že MS o podobných krocích opravdu uvažuje. Ad co mělo být ve Windows Vista - něco bylo opravdu vyškrtnuto. Pořád toho zbylo tolik, že je to zřejmě nejlepší OS na trhu. Vyjma architektury, která je u NT řady před unixy napřed, tu máme .NET Framework coby velmi dobré prostředí (WPF zřejmě překope i web). Svými features mu konkurence nesahá ani po kotníky, to snad vidíte. Ve Vistě jsou i lahůdky typu prioritizovaný I/O, plně ACID transakční file system atd.
  • 3. 1. 2007 21:32

    Miloslav Ponkrác_ (neregistrovaný)
    ...........Unix je jeden, uměle rozbitý do různých navzájem mizerně kompatibilních produktů.

    Unix je především princip. Vaše věta je poněkud ...

    ........Na Singularity samozřejmě běží také stroják. CIL se přeloží do strojáku, a ten se pak pouští. Při překladu z CIL do strojáku se zjišťuje, zda kód vyhovuje kritériím. U výsledného strojáku už nemá smysl mluvit o virtual machine.

    Na Singularity neběží stroják, protože tam nespustíte binárku se strojákem. Vnitřní záležitosti Singularity vynechme, protože taky netvrdím, že na Windows běží interní mikrokód procesorů x86, ačkoli to tam někde uvnitř překladá procesor ze strojáku do mikrokódu a v podstatě tam přímo stroják neběží.

    .........Ad Win32 smí vše co mu systém dovolí - to jistě ano :). Nicméně trochu pomíjíte rozdíl mezi současným stavem (Win32 sandboxing existuje, ale má omezení), a mezi řekněme během Win32 aplikací na virtuálních strojích.

    Ano existuje. Ale pořád bude platit, že Win API bude smět jen to co mu dovolí systém, který je tu od toho aby také omezoval a řídil prostědky počítače.

    ...........Ad budoucnost - já dokládám, že MS o podobných krocích opravdu uvažuje.

    A já dokládám, že uvažování je jen spekulace. Ač nemám nic proti MS a nutno uznat, že dotáhli spoustu věcí do praktického stavu, přeci jen jejich vize jsou často ve stylu JPP.

    ...........Ad co mělo být ve Windows Vista - něco bylo opravdu vyškrtnuto. Pořád toho zbylo tolik, že je to zřejmě nejlepší OS na trhu.

    Marketinková vložka :-)

    .........Vyjma architektury, která je u NT řady před unixy napřed

    a proto se unix používá tam kde je potřeba velký výkon, spolehlivost, atd. atd. :-) ale asi tam všichni brzo nasadí Visty :-))))

    člověče, v něčem je NT napřed a v něčem ne, jako všechno

    ..........tu máme .NET Framework coby velmi dobré prostředí (WPF zřejmě překope i web).

    nic proti .NET, je to dobrá věc. zbytek je další rádobyvize :-)

    .............Ve Vistě jsou i lahůdky typu prioritizovaný I/O, plně ACID transakční file system atd.

    Já jsem nikde netvrdil, že Microsoft nedělá dobré věci.

    P.S.: Ve Vistě je i DRM, které zničí kvalitu audio a video výstupů a zatěžuje počítač. To jen tak na okraj, protože díky Vistě se nebudeme zbytečně rozmazlovat kvalitními multimédii, na to je ten unix a linux.
  • 3. 1. 2007 22:03

    K2 (neregistrovaný)
    UNIX je ochraná známka The Open Group, a systém je vyvinutý v AT&T. Pozdější deriváty zanášejí nekompatibility, mnohdy záměrně. Viz Unix wars.

    Flame jestli Singularity je nebo není OS mě nepřipadá relevantní. Samozřejmě nemožnost spuštění libovolné binárky je daní za zvolený způsob oddělení procesů. Pokud je ale systém postavený na CIL (jako unixy na C), není to problém.

    Ad kde je potřeba velký výkon a spolehlivost - Intel HW není ten nejvýkonnější. Pokud firma v roce 2002 potřebovala vyzkoušenou 64-bit platformu pro běh databáze nad 1TB velikosti, 64-bit unix byl mnohdy logickou volbou. Dnes se situace opět mění. Řada firem má DB v řádu TB, s obrovskou zátěží, jedoucí na Wintelu. Visty se na to kupodivu nepoužívají - Windows mají i serverovou edici :)

    Ad "zničení kvality audio a video výstupů" - to není pravda. Pokud přehráváte média, která autoři uvolnili s tím, že mají nějaká omezení (třeba audio nesmí projít přes SPDIF výstup), je toto omezení vynuceno. Většina z nás si chráněné médium nikdy nekoupila, a je otázkou, jestli ho kdy koupí (rozhodně to není povinné). Tu údajnou zátěž počítače ještě nikdo nezměřil. Je otázka, zda se kontroly HW týkají jen doby, kdy se přehrává chráněné médium, nebo obecně. Je otázka, kolik výkonu to bude stát. Odmítám se ale podílet na FUD na toto téma.
  • 3. 1. 2007 22:35

    Miloslav Ponkrác_ (neregistrovaný)
    ............UNIX je ochraná známka The Open Group, a systém je vyvinutý v AT&T. Pozdější deriváty zanášejí nekompatibility, mnohdy záměrně. Viz Unix wars.

    Unix je ochranná známka a také princip.

    ...........Samozřejmě nemožnost spuštění libovolné binárky je daní za zvolený způsob oddělení procesů. Pokud je ale systém postavený na CIL (jako unixy na C), není to problém.

    Unixy nejedou na C, pouze jsou programovány převážne v C. Stejně tak Singularity nejede na C#, ale pouze v tomto může být programován. To v obou případech nevylučuje ani jiné technologie.

    ..................Ad kde je potřeba velký výkon a spolehlivost - Intel HW není ten nejvýkonnější.

    To nikdo tady netvrdil.

    ...........Pokud firma v roce 2002 potřebovala vyzkoušenou 64-bit platformu pro běh databáze nad 1TB velikosti, 64-bit unix byl mnohdy logickou volbou. Dnes se situace opět mění. Řada firem má DB v řádu TB, s obrovskou zátěží, jedoucí na Wintelu. Visty se na to kupodivu nepoužívají - Windows mají i serverovou edici :)

    Dovolil bych si pípnout, že unix se přeci jen nasazuje na kritičtější místa, kde na spolehlivosti záleží častěji a zřejmě to tak bude i nadále a obávám se že ještě tomu tak velmi dlouho bude. To nijak nepopírá samozřejmě Vaše tvrzení.

    ...............Ad "zničení kvality audio a video výstupů" - to není pravda. Pokud přehráváte média, která autoři uvolnili s tím, že mají nějaká omezení (třeba audio nesmí projít přes SPDIF výstup), je toto omezení vynuceno.

    Takže je to pravda, prostě nemám kontrolu nad multimédii, ale cosi bez mého zásahu ovládá kvalitu výstupů a vypíná výstupy. Troufám si říci, že třeba Linux tento zmetek v sobě mít na 99,99999% nebude.

    ................Většina z nás si chráněné médium nikdy nekoupila, a je otázkou, jestli ho kdy koupí (rozhodně to není povinné).

    Ale spousta z nás si koupila médium s ochranou, aniž o tom věděla, a aniž takové médium bylo označeno. Často i prodejce se divil. Takže koupě média s ochranou je zážitek poměrně rozšířený.

    ............Tu údajnou zátěž počítače ještě nikdo nezměřil.

    Ono je jaksi logické, že když počítač navíc vnitřně kryptuje, ačkoli by nemusel, kdyby tzv. "nechránil autorská práva", že jeho zátěž se zvýší.

    ................Je otázka, zda se kontroly HW týkají jen doby, kdy se přehrává chráněné médium, nebo obecně. Je otázka, kolik výkonu to bude stát. Odmítám se ale podílet na FUD na toto téma.

    Je ale třeba aby se to zahrnulo do debat, a aby se tu uvedlo, že tuto svělou featuru Vista má. Detaily jsou dobře známy, doporučuji cdr.cz a nebo blog abclinuxu.cz, kde byly velmi detailní informace včetně velmi podrobného vysvětlení principu jak to ve Vistách funguje. FUD to rozhodně není a je to hnus velebnosti.
  • 3. 1. 2007 23:45

    K2 (neregistrovaný)
    Ano, business critical aplikace jsou z těch posledních, kde se unixy drží. Jedním z důvodů jsou existující obchodní vztahy (jinými slovy obchodníci IBM a Sunu neradi přepouštějí zákazníky jiným firmám). Pak je to setrvačnost trhu. Dalším důvodem je cílení Windows na mainstream trh; okrajové části trhu nejsou pro MS tolik zajímavé.

    Ad DRM - vydavatelé obsahu mají zájem prodávat online. Bojí se, že prodají film v jedné kopii, a zbytek lidstva si ho stáhne z BitTorrentu. Zkušenost ukazuje, že obava je oprávněná. Těžko vydavatelům odepřít jejich práva k obsahu; ten obsah je jejich. MS se trvale snaží těm firmám nabídnout prostředí, ve kterém je možné média přehrávat s omezeními, která si vydavatel zadá. Osobně mi taková feature Windows Vista nevadí, ale taková média si zřejmě nekoupím. Linux "tento zmetek v sobě mít na 99,99999% nebude", protože to u něj není technicky možné. Pokud je totiž třeba docílit toho, aby nebylo možné médium vykrást třeba použitím driveru zvukové karty zapisujícího výstup na disk, je to v principu nekompatibilní s open source :)

    Ad média s ochranou - tohle je jiný typ ochrany, a měla by být vždy označena. Ad výkon - vím, jak to funguje. Nikde jsem ale nedohledal, že by docházelo ke snížení výkonu, dokud nejde o přehrávání obsahu chráněného danou metodou. Nakonec pokud nepřehráváte tento obsah (znovu říkám, že je otázka, zda ho kdy bude někdo přehrávat), žádná omezení se vás netýkají. Osobně mám za to, že se ta ochrana minimálně nějakou dobu neprosadí. Například klasické DVD přehrávače skoro nikdo nechce měnit za HD-DVD a BluRay, a CD skoro nikdo nechce nahrazovat DVD Audiem. Vydavatelé mají možnost se ucházet o naší přízeň s "chráněnými" tituly, a my máme možnost je odmítnout.
  • 4. 1. 2007 0:18

    Miloslav Ponkrác_ (neregistrovaný)
    .......Ano, business critical aplikace jsou z těch posledních, kde se unixy drží. Jedním z důvodů jsou existující obchodní vztahy (jinými slovy obchodníci IBM a Sunu neradi přepouštějí zákazníky jiným firmám). Pak je to setrvačnost trhu. Dalším důvodem je cílení Windows na mainstream trh; okrajové části trhu nejsou pro MS tolik zajímavé.

    Zapomínáte taky na to, že se tam Unixy drží kvůli svým vlastnostem.

    ...............Ad DRM - vydavatelé obsahu mají zájem prodávat online. Bojí se, že prodají film v jedné kopii, a zbytek lidstva si ho stáhne z BitTorrentu. Zkušenost ukazuje, že obava je oprávněná. Těžko vydavatelům odepřít jejich práva k obsahu; ten obsah je jejich. MS se trvale snaží těm firmám nabídnout prostředí, ve kterém je možné média přehrávat s omezeními, která si vydavatel zadá. Osobně mi taková feature Windows Vista nevadí, ale taková média si zřejmě nekoupím. Linux "tento zmetek v sobě mít na 99,99999% nebude", protože to u něj není technicky možné. Pokud je totiž třeba docílit toho, aby nebylo možné médium vykrást třeba použitím driveru zvukové karty zapisujícího výstup na disk, je to v principu nekompatibilní s open source :)

    No já sice vydavatele chápu, ale odcaď pocaď. Nemám si snad kvůli vydavatelům rovnou nechat naimplantovat stěnici? Prostě operační systém chci ovládat sám a taková feature mi prudce vadí. Taková média si mimochodem pravděpodobně několikrát za život koupíte, neboť nejsou ani řádně označována. V některých jiných státech došlo k hromadným žalobám, ale tady jsme papežštější, než papež. Nepotřeuji open source, potřebuji operační systém, který není řízen centrálou nějaké vzdálené vydavatelské firmy, což se v případě DRM děje.

    ...............Ad média s ochranou - tohle je jiný typ ochrany, a měla by být vždy označena.

    Slovo "měla označovat" je něco na co vám vydavatelé opravdu ale srdečně kašlou, jak se zatím ukazuje.

    .............Ad výkon - vím, jak to funguje. Nikde jsem ale nedohledal, že by docházelo ke snížení výkonu, dokud nejde o přehrávání obsahu chráněného danou metodou.

    Víte, oni fungujou fyzikální zákony i tehdy, když je na netu nedohledáte. Věřte mi to. :-)

    .............Nakonec pokud nepřehráváte tento obsah (znovu říkám, že je otázka, zda ho kdy bude někdo přehrávat), žádná omezení se vás netýkají.

    Pokud to budu vědět.

    ..............Osobně mám za to, že se ta ochrana minimálně nějakou dobu neprosadí. Například klasické DVD přehrávače skoro nikdo nechce měnit za HD-DVD a BluRay, a CD skoro nikdo nechce nahrazovat DVD Audiem. Vydavatelé mají možnost se ucházet o naší přízeň s "chráněnými" tituly, a my máme možnost je odmítnout.

    Takže nakonec budeme omlouvat DRM přímo v systému, který bude rozhodovat za nás a je to. Mě tohle neuspokojuje. Koukejte, mám Windowsy rád, uznávám všechny novinky i možnosti Visty, ale DRM v jádře je všechny přebije v mém pojetí do stavu "velmi špatného systému".

    Jsem schopen obhajovat Windows, pokud tedy někdo není fanatik ve stylu "mám raději .NET, než sex", a sám na desktopu jedu výhradně na Windows, protože mi vyhovují víc. Osobně si myslím, že Windows nakonec zachrání to, že to někdo crackne, jinak by měl Linux podstatné body navíc.
  • 4. 1. 2007 20:08

    K2 (neregistrovaný)
    Ad DRM - operační systém přeci ovládáte sám. Jinak média chráněná popsaným postupem je možné koupit online, na HD-DVD nebo BluRay. Se současnými způsoby "ochrany" (třeba zmršenými audio CD) a jejich (ne)značením to nemá nic společného.

    Jinak postoj vydavatelů je daný případy Napster, BitTorrent apod. Masivně se krade něčí majetek, a nikdo s tím není schopen nic dělat. Nikdo nemůže tvrdit, že bez posledního alba Tokio Hotel stáhnutého z BitTorrentu nemůže žít; nikdo krást nemusí. Tak rozsáhlé porušování práva vydavatelů je alarmující, to si přiznejme. Vysoká cena médií neopravňuje ke krádeži. Když vydavatelé jdou po uživatelích P2P sítí, je to prý špatně. Když chtějí vydávat média tak, aby se krást nedala, je to prý špatně. Mají se podle vás nechat okrádat?

    Ad výkon - fyzikální zákony jsou mimo téma. Při přehrávání chráněných médií se provádí periodické kontroly HW, a data se šifrují všude po cestě. To stojí výkon. U nechráněných médií tomu tak není.

    Ad "DRM v jádře je špatné" - jenže ono je tam už ve Windows XP. Zkuste si přehrát audio koupené online v nějakém eshopu za pomoci driveru zvukové karty, který není certifikovaný. Nelze, protože celý řetězec (dekodér, driver zvukové karty) musí být certifikovaný. Vista pouze zavádí navíc šifrování chráněného obsahu po cestě ven z počítače, a odepínání nechráněných výstupů.

    Ad "mám raději .NET než sex" - za sebe musím říci, že mám daleko raději sex.
  • 4. 1. 2007 23:05

    Miloslav Ponkrác_ (neregistrovaný)
    Koukejte, kvůli tomu že se znásilňuje se taky nepřistoupí k hromadnému vykastrování všech potentních mužů. A přitom m tenhle způsob připomíná řešení ve Vistě.

    Je mi vydavatelů líto, ale je nesmysl kvůli tomu obhajovat ovládání operačního systému, kdy ani administrátor nemá systém pod kontrolou a řídí ho n
  • 4. 1. 2007 23:31

    Miloslav Ponkrác_ (neregistrovaný)
    Koukejte, kvůli tomu že se znásilňuje se taky nepřistoupí k hromadnému vykastrování všech potentních mužů. A přitom m tenhle způsob připomíná řešení ve Vistě.

    Je mi vydavatelů líto, ale je nesmysl kvůli tomu obhajovat ovládání operačního systému, kdy ani administrátor nemá systém pod kontrolou a řídí ho nastavení na nějaké placce a systém mu podle toho tu odstaví výstupy, nebo nějakou hw v počítače. Ať si vydavatelé najdou adekvátní řešení, a tím řešením rozhodně není nasazení takové debility dovnitř operačního systému.

    Jinak já nekradu, ani ke krádeži nenabádám, takže si nechte toho moralizování. Děkuji.

    Taky bych rád, kdyby vydavatelé kromě prznění médií a neustálém prohlašování všechny za zloděje, by měli také nějaké povinnosti. Minimálně alespoň tu, že by museli označovat zřetelně (řekněme jako u krabičky cigaret) povinně označit CD označením, že je tam ochrana ve velikosti alespoň 30% krabičky, když nic jiného. Dnešní stav, kdy to běžně není označeno vůbec. A aby nedodržení této povinnosti se trestalo pokutou řekněme ve výši 20% ročního obratu společnosti za každý vydaný neoznačený titul.

    Taky by se vydavatelé měli zamyslet nad tím, že mnoho lidí už se bojí originálních CD. Buď se bojí ochrany, nebo nějakého ochranného spyware (zdravím tímto Starforce), které je schopno likvidovat funkce systému, nebo dokonce ničit hw. Toto je určitě krok správným směrem.

    Navíc poslední vyhláška o autorských poplatcích zlikvidovala i mnoho čestných lidí, protože dost lidí pochopí, že za dílo se musí platit, ale už nepochopí, že Gott, Vondráčková i další dostávají peníze, i když nic nedělají prostě za nic. Já sám nechápu, proč při distribuci mých programů dostává Gott a Vondráčková peníze. Proč při kopírování mých věcí dostává Gott a Vondráčková můj podíl. Vůbec se nedivím, že pak lidé nepovažují za nemorální krást, když Gott a Vondráčková nepovažují nenormální parazitovat. Pokud vydavatelé řeší své problémy tímto způsobem, je mi jich líto. Prostě musí padnout na čumák, dokud nepochopí, že odcaď pocaď.
  • 5. 1. 2007 4:38

    K2 (neregistrovaný)
    Kdyby bylo znásilnění celkem běžným zločinem, jistě by bylo nutné přitvrdit postihy.

    Nesnažím se moralizovat, ale vysvětlovat. Faktem je, že velká většina uživatelů počítačů krade buď SW, nebo média. Pokládat uživatele počítačů za zloděje tedy bohužel není tak daleko od pravdy.

    Administrátor obecně systém nemá zcela pod kontrolou. A jak jsem říkal, nemá ho pod kontrolou ani v XP (a nakonec ani nikde jinde). Na druhé straně tento fakt nikoho neomezuje.

    S povinným označováním chráněných médiíí 100% souhlasím. Případnou škodu způsobenou neznačením, poškozením HW apod. lze řešit v občansko-právním řízení.

    Poplatek v ceně záznamových materiálů (DVD média apod.) je zamýšlen jako odměna autorům za legální domácí kopírování. Když si koupíte CD, můžete si udělat legálně kopii; autor neprodá další médium, vy ušetříte (vašimi slovy parazitujete). Aby autoři nepřišli zkrátka, dostávají nějakou částku paušálem z každého média. Částka je samozřejmě věcí lobbování.

    Strach z orig médií bych neviděl jako problém. Osobně jsem nenarazil na žádné, na kterém by nebylo varování (a takové jsem si nekoupil). Strach je na místě mimo jiné v případě P2P sítí, protože postih je možný i v ČR (nevím, jestli už se tak stalo).
  • 5. 1. 2007 8:28

    Miloslav Ponkrác_ (neregistrovaný)
    Pořád i kdyby znásilnění bylo běžným zločinem, přeci jenom kastrace všech mužů nebylo přijatelným řešením, byť by určitě problém jednoduše řešilo. Nejjednodušší řešení nejsou vždy ty nejlepší.

    Administrátor má v dobrých operačních systémech věci zcela pod kontrolou. Zdůrazňuji v dobrých. Pokud ne, nejedná se o dobrý operační systém.

    Co se týká škody, neřešil by škodu v označování, protože se jedná o nadnárodní giganty. Ono bohatě stačí O2 versus ČTÚ, kde O2 se směje, protože se mu vyplatí porušovat zákony, protože pokuta je pro něj směšná a zisk z porušení zákona značný. Proto bych prostě při neoznačeném titulu automaticky napařil značnou pokutu bez ohledu na výši škody a navrhnul jsem 20% ročního obratu, což je pro každou firmu opravdu citelné na to, aby se jí vyplatilo zákony nedodržovat.

    Pokud je poplatek v ceně médií zamýšlen jako odměna autorům za domácí kopírování, proč tedy na kopii není právo? Proč tedy ochrana na hudebních CD není rovnou zákonem zakázána, protože zabraňuje udělat kopii - tedy to co platíte. Proč dokonce obcházení ochrany je dokonce trestným činem? Vážený pane, takhle to není, možná oficiálně je poplatek za právo na kopii, ale ve skutečnosti ho platíte, i když vám zákon tu kopie zakazuje udělat pod trestem vězení. Takže se domnívám, že něco tu smrdí. A důvodně se domnívám, že lidé nedostávají to, za co si poplatek platí a proto platí jen za parazitování Gottů a Vondráčkových. Takže znovu poplatek je nemorální a nic za to člověk nedostává. Oficiální zdůvodnění, že je to poplatek za domácí kopírování je lež, když toto kopírování autorský zákon kriminalizuje.

    Strach z originálních médií mnoho lidí jako problém vidí. Koupě média s ochranou, aniž by na médii nebylo ani pípnutí o ochraně je tak běžné.
  • 6. 1. 2007 0:40

    K2 (neregistrovaný)
    Ad "zcela pod kontrolou" - to je vždy iluze. Ad 20% - to je likvidace, nikoliv trest. Ad poplatek - souhlasím, že zvýšení poplatků za prázdné nosiče a zároveň zamezování kopírování je špatná kombinace. Ad orig média - jak říkám, já je vždy viděl označená.

    No na některých věcech se neshodneme, ale v principu to byla dobrá diskuze. Myslím, že se ještě uvidíme.
  • 2. 1. 2007 23:06

    Miloslav Ponkrác_ (neregistrovaný)
    Nikdo není shcopen říci co bude. Například se může ukázat .NET jako slepá cesta, nebo jako méně výhodná cesta a nahradí ji něco jiného. Například a klidně se to může stát.

    Stejně tak neexistuje jenom .NET a Win32 a kernel API, ale asi tak obrovská spousta (tisícovky) dalších možností. Například je možné psát v s dalších prostředcích a technologiích. Je blbost je stavět kontra proti sobě dvě (či tři) možnosti a tvářit se, že nic jiného na výběr není.

    Takže nadšení pro .NET je hezká věc, není to špatná technologie, ale takových už tu bylo, že.
  • 31. 12. 2006 19:37

    Miloslav Ponkrác
    Jasně, a všechno se bude na všech procesorových platformách (i těch co nedisponují syscallem) a ve všech verzích Windows volat pomocí kernel mode věci. Nehledě na to, že používat v mnoha programech kernel mode interface je značně (zejména ekonomicky) nepraktické už kvůli větší proměnlivosti tohoto rozhraní.

    Win API bude vždy pro user mode věci základ a ve Win API bude vždy nadřazeno jakémukoli jinému rozhraní. I v .NETu půjde udělat pouze podmnožina toho, co lze udělat ve Win API. Je sice teoreticky možné, že Win API bude pouze emulováno, ale je to tak nepravděpodobné, že to neberu ani moc v úvahu pokud se bavíme o Windows samotných.

    Mimochodem v Unixem je to stejně, také existuje kernel mode rozhraní, ale ještě nikdo nevypouští podobné debility ve stylu, že hlavní rozhraní bude Java a mnoho nových věcí v Linuxu půjde napsat jen v Javě, ale v ničem jiném, abych napsal něco analogického. A přitom je to naprosto stejná hovadina jako s tím, že nové věci půjdou ve Windows jen v .NETu. Prosím přestaňte už s těmi bláboly o .NETu. Nepleťte si skutečnost s marketinkovými kecy, které napíše nějaký senzacechtivý novinář, nebo blogger.
  • 30. 12. 2006 23:24

    bez přezdívky
    Ted jsem si po sobe precetl puvodni prispevek a uz vim, kde doslo k nedorozumneni. Melo tam byt to, ze Win32API uz nebude samostatne. Podle vseho se uz nejedna o 2 ruzna rozhrani, ale WinFX implementuje i funkce stareho Win32API. Uz nebude tak intenzivne vyvijeno (narazilo na hranici rozsiritelnosti) a nove aplikace by mely pouzivat WinFX (.NET3.0).
    Ale v sandboxu asi jen tak nepobezi. Podle for MSDN jej stale vyuziva WinFX a vyuziva ho i spousta komponent systemu (jinak by se ten molochoidni system uz temer nehnul) + napr. MSOffice.
    Ale pocital bych s tim, ze kazda dalsi verze Widli odsoudi k nefunkcnosti vice programu nez jakakoliv predesla.
    Na druhou stranu se ho nemohou uplne zbavit - unmanaged kod by nemel kde bezet a musel by se pouzivat mix managed/unmanaged. V C# to jde. V C by byl problem (nepocitam-li pripad, ze hlavni casti programu by byly C knihovny importovane k castem interagujicim se systemem, ktere by byly v .NETu - to je trochu obracena architektura:).
  • 30. 12. 2006 23:42

    Miloslav Ponkrác
    Ach jo, tohle je fakt naposled co zareaguju na tyhle věci.

    Především MS se velmi snaží, aby každá další verze Windows byla maximálně kompatibilní s existujícími programy. Až se o to přestane snažit, pak linuxová komunita se může s prominutím ožrat radostí, protože nic lepšího pro rozšíření Linuxu není. A MS to ví. Pokud mi někdo bude chtít argumentovat, že program X v další verzi Windows nepůjde, tak bych ho chtěl upozronit, že pokud nepůjde dvacet programů z miliónu, je to stále výborná kompatibilita, o které si Linux může nechat vzdáleně pouze zdát. Tolik k tomu nesmyslu "Ale pocital bych s tim, ze kazda dalsi verze Widli odsoudi k nefunkcnosti vice programu nez jakakoliv predesla."

    K ostatnímu už fakt nemám sílu se vyjadřovat.
  • 27. 12. 2006 22:46

    ventYl
    problem je v tom, ze uzatvorene veci sa nesmu distribuovat spolu s otvorenymi... vid. proprietarne drivery od nvidie a ati v kororoa live CD