Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - Filip Jirsák

Stran: 1 ... 363 364 [365] 366 367 ... 375
5461
Ten, kdo koupí software z druhé ruky, se stává "oprávněným nabyvatelem rozmnoženiny" (toto platí podle evropského práva, kterému je české právo podřízeno):

... Soudní dvůr odpověděl, že každý následný nabyvatel rozmnoženiny, ve vztahu k níž je právo nositele autorského práva na rozšiřování vyčerpáno, je v tomto smyslu oprávněným nabyvatelem.
Ano, tak to je, všichni tady s tím souhlasí a není potřeba to opakovat stále dokola.

"Oprávněný nabyvatel rozmnoženiny" může svou rozmnoženinu užívat na základě tzv. "zákonné licence", tj. podle §66 autorského zákona (toto platí podle českého práva):

"(1) Do práva autorského nezasahuje oprávněný uživatel rozmnoženiny počítačového programu, jestliže
a) rozmnožuje, překládá, zpracovává, upravuje či jinak mění počítačový program, je-li to nezbytné k využití oprávněně nabyté rozmnoženiny počítačového programu"
(autorský zákon, §66)
Žádná zákonná licence pro software neexistuje. Existuje volné užití autorského díla, které se ale výslovně netýká software, a existují zákonné licence, které nelze na software aplikovat.

§ 66 odst. 1 říká, jaká minimální práva má oprávněný uživatel. Oprávněným uživatelem se ale někdo stane až tehdy, když uzavře licenční smlouvu s autorem, nebo když takovou licenční smlouvu koupí z druhé ruky.

Jinak ten §66 mi přijde poměrně logický: Představte si, že si z druhé ruky koupíte mobilní telefon. V něm je software, a dejme tomu, že výrobce telefonu v licenčních podmínkách stanovil nějaká omezení. Pokud by §66 neexistoval, vy jako nový majitel byste musel zjišťovat, jaký je obsah licence a zda telefon vůbec smíte používat.
Ano, to si nový majitel samozřejmě zjistit musí. Nelogická by byla vaše interpretace, kdy by autor způsob užití v licenci nějak omezil, ale přeprodejem by ta omezením zmizela. Pak by samozřejmě nikdo nic nekupoval z první ruky, vše by se nejprve fiktivně přeprodalo a tím pádem by nikdo nebyl vázán licencí. Veškeré licence by tak ztratily smysl.

Ale brání: Uživatel je oprávněn vytvořit si pouze takový počet rozmnoženin, který je nezbytný k užívání programu:

Použití na ostatních 99 počítačích už nezbytné není, práva vlastníka rozmoženiny se naplnila na prvním počítači.
Když potřebuju (jako firma) program používat na 100 PC, mohl bych si vytvořit 100 rozmnoženin.

Podobně i rozsudek ve věci UsedSoft
V tom rozsudku není ani slovo o tom, že by nabyvatel z druhé ruky měl víc práv, než má první nabyvatel. Naopak se tam opakuje, že má stejná práva, jako původní nabyvatel. Pořád se jedná pouze o to, že autor nemůže omezit nakládání s licencí (licenci můžu prodat dál), ale ta licence je stále platná a ten, kdo jí koupí, se jí stále musí řídit - pokud tak nečiní, nemá k užívání programu žádné právo.

5462
Ale to se mýlíte: tady se mluví o tom, že není pravda že by licence byla platná:

"Je přitom nerozhodné, zda má výrobce ve smlouvě (licenční nebo jiné) uvedeno ujednání, které omezuje možnost disponování se staženým softwarem – např. v předmětném sporu měl Oracle mj. ustanovení o tom, že „užívací právo“ k software je „nepřevoditelné“. ESD konstatoval, že takto by institut vyčerpání autorských práv neměl žádný význam, když by nositel autorských práv mohl vyloučit touto cestou jeho účinky."
Ne, tady se nemluví o tom, že by licence nebyla platná. Tady se za prvé mluví o smlouvě (licenční nebo jiné) -- takže žádný váš § 66 odst. 1. Za druhé se zde mluví o tom, že výrobce v licenci nemůže stanovit, jak může nabyvatel nakládat s licencí -- protože autorovo právo nakládat s licencí je platné jen do té doby, než tu licenci někomu prodá, pak už to právo má nový nabyvatel. Pořád se to ale týká nakládání s licencí, nikoli samotného obsahu licence - ten je závazný pro prvního nabyvatele i pro kteréhokoli dalšího.

Když máte pořád problém chápat to u softwarových licencí, představte si to třeba na směnce. A je dlužník, B věřitel. A vystaví směnku "Já, A, dlužím vlastníkovi této směnky částku 10 Kč". B teď může vzít tuhle směnku a prodat jí C. A do toho (v případě licencí) nemůže nijak mluvit - on měl právo nakládat s tou směnkou, dokud ji držel v ruce, ale předáním B se tohle jeho právo vyčerpalo a teď to právo má B. To předání směnky od B k C ale nijak neovlivňuje obsah té směnky - pořád znamená, že A dluží držiteli směnky 10 Kč. V případě OEM licence to pak je, jako kdyby na té směnce bylo uvedeno "já, A, dlužím B částku 10 Kč". B tuhle směnku také klidně může prodat dál, ale kdo by si ji koupil - A pořád dluží B, takže nový majitel by z toho nic neměl.

Ten odkaz na Lupu už tady byl, a podle mého názoru je ten článek zmatený. Licenční smlouva je smlouva o převodu užívacích práv, která jsou v té smlouvě specifikována. Příjemce je může prodat dál, ale nemůže prodat práva, která nezískal. Třetí osoba je tedy tou licenční smlouvou také vázána, i když to není smlouva uzavřená přímo mezi ní a autorem. Když stavebník prodá dům majiteli s nějakými podmínkami, může jej druhý majitel prodat třetímu jedině s těmi samými podmínkami (případně si může přidat další). Třetí majitel tedy nemá smlouvu se stavebníkem, ale přesto je podmínkami té smlouvy vázán. Nemůžete říct, že třetí majitel se stavebníkem žádnou smlouvu nemá a tudíž mu ze zákona náleží vše, co ten stavebník kdy postavil.

Proč myslíte, že je možné jednu rozmnoženinu nainstalovat na 100 počítačů?
Tam, kde platí současný AZ, mu v tom zpravidla brání licenční ujednání. Pokud by ale pro někoho licenční ujednání neplatilo a řídilo se to jen § 66 odst. 1 vykládaným jako "autor nesmí oprávněnému uživateli nijak bránit užívat program", nemohl by autor majiteli rozmnoženiny nikam bránit v užívání programu. A pokud by majitel chtěl používat program na 100 PC (třeba u firmy se 100 zaměstnanci), nic by mu v tom nebránilo a nesmělo bránit.

5463
Server / Re:Co když ztratím SSH klíč?
« kdy: 28. 01. 2014, 21:12:26 »
Co by zloděj/útočník získal, kdyby se mu můj privátní klíč dostal do ruky? Mám to přece ještě zaheslovaný...
Nevím přesně, jak vypadá ten zaheslovaný soubor - zda po "odheslování" je hned zřejmé, zda bylo heslo správně (případně se to dá určit s nějakou pravděpodobností, nebo zda pod odheslování i správným heslem dostanu něco, co vypadá jako náhodná změť znaků, a musím to zkusit poslat na server, od kterého se teprve dozvím odpověď (správný/špatný klíč).

Pokud platí první případ, je problém v tom, že lokálně je možné ta hesla zkoušet mnohem rychleji, a útočník v tom není nijak omezen. Klidně to louskání může distribuovat na víc počítačů - a pak i na první pohled ne úplně slabá hesla jsou prolomitelná. Opravdu silná hesla odolají i tomuhle útoku.

Pokud platí druhá varianta, musí útočník zkoušet klíč proti vašemu serveru. Což jednak půjde výrazně pomaleji, jednak tam můžete mít nějaké limity, že pokud někdo zkouší po milionté špatný klíč, asi bude něco špatně. Je to pak vlastně (co do možností útočníka) stejné, jako byste se nepřihlašoval klíčem, ale heslem stejným, jako je to heslo ke klíči.

5464
Argumenty jste ráčil ignorovat. Na minulé stránce jsem posílal odkazy na dva rozbory specialistů na IT právo:
http://www.pravoit.cz/article/prodej-software-z-druhe-ruky-je-to-legalni
http://www.pravoit.cz/article/prodej-pouziteho-softwaru-zasadni-rozhodnuti-esd-v-kauze-usedsoft
Nikoli, ty argumenty jsem neignoroval. Ty články (jak už jsem mnohokrát psal) se týkají vyčerpání práv. Tj. autor stanoví licenci pro nějaké dílo, a tuto licenci prodá. Tím se ale vyčerpala jeho práva k rozhodování o té licenci, a nabyvatel té licence s ní dál může nakládat dle svého uvážení. Samozřejmě ji nemůže změnit, ale může ji vzít tak jak je a prodat ji někomu třetímu. A pro tu třetí osobu je ta licence stejně platná, jako byla pro původního nabyvatele.

O tom, že by existovalo nějaké volné užití pro software, není v těch článcích ani ň. Naopak se tam všude píše jen o užití díla na základě smlouvy uzavřené s autorem. Takže děkuji za další články, které vyvrací vaše tvrzení.

Jinak pokud by platil ten váš výklad, je stejně nesmysl nakupovat u vyhodny-software.cz nebo vůbec nakupovat nějaké OEM licence.  Stačilo by koupit libovolnou nejlevnější licenci (třeba upgrade pro studenty), nebo dokonce jen instalační médium, a z toho (podle vás legálně) nainstalovat třeba sto počítačů ve firmě.

5465
Úvaha, která se selským rozumem nabízí, je zřejmá - životnost SW zejména v dnešní době značně přesahuje životnost HW
Takže jste úvahou došel k tomu, že vám se nevyplatí OEM licence, ale jsou pro vás výhodnější krabicové verze. To vám nikdo nebere a nikdo vám nebrání je kupovat. Akorát to nijak nesouvisí s touto diskusí, protože tady se řeší právě OEM licence.

To je opravdu lepší koupit Windows z druhé ruky a používat ho na nelicenčním základě, tj. podle § 66 odst. 1 autorského zákona.
Je hezké tohle s takovou jistotou tvrdit na konci diskuse, ve které se dlouze diskutovalo o tom, jestli nějaké nelicenční užití vůbec je možné - a nikdo nebyl schopen dát přesvědčivý argument o tom, že to možné je. Já se svou domněnku nebudu pokoušet podstrčit jako fakt - podle mého názoru je vaše interpretace § 66 odst. 1 AZ mylná, vysvětlení můžete hledat na předchozích stranách této diskuse.

5466
Odkladiště / Re:Zatopení hostingu Casablanca
« kdy: 25. 01. 2014, 18:30:52 »
jenom mi je neustále tvrzeno, že vývoj jde nějakým směrem, že mám jet s tím proudem. Přitom vidím poměrně zásadní vady na celé té kráse."
To si ale pletete pojmy s dojmy. Vývoj jde tím směrem, že se od poskytování hardware a programů a přenosových linek postupně přesouváme k poskytování služeb. Dnes už zdaleka není tak běžné nakupovat zvlášť datové okruhy, zvlášť konektivitu na portu někde v NIXu -- většina zákazníků to kupuje najednou jako "připojení k internetu". A podobně se to posouvá i v celém IT (a nejen tam) -- uživatel většinou nepotřebuje padesát kilo disků, SQL server a ERP aplikaci, on potřebuje evidovat skladové zásoby, vystavovat faktury atd. To jsou všechny ty možné PaaS a IaaS a SaaS...

Cloud je jenom jeden ze způsobů, jak některé z těch služeb provozovat. Je dost nešťastné, že se z toho stal marketingový pojem pro koncové uživatele, protože těm vůbec není určen. Já chci GMail jenom používat, je mi jedno, jak si to provozovatel zařídí a jestli k tomu použije zrovna cloud nebo něco jiného.

No a protože je to vše docela nové a není pro to ustálená terminologie, kde kdo si tak pojmenuje své produkty, i když to třeba s cloudem nemá nic společného. Nebo někdo má opravdu v úmyslu provozovat tu službu tak, jak ta služba má vypadat, ale prostě to neumí. To ale neznamená, že ta technologie jako taková nefunguje. Akorát se neznalému člověku těžko předem rozlišuje mezi podvodníkem, nešikou a někým, kdo to dělá dobře.

5467
Odkladiště / Re:Zatopení hostingu Casablanca
« kdy: 25. 01. 2014, 11:34:39 »
P.S. Data v cloudu == data v čoudu.
Jistě. Těm ostatním necloudovým serverům ta koupel jenom prospěla, aspoň se pročistila dlouho nepoužívaná zákoutí pevných disků a servery teď běží o to lépe. Majitelé si to pochvalují a už plánují pravidelné koupání serverů, někteří je možná vezmou i k moři.

Mezi představou, že cloud = 100 % dostupnost služeb, a tvrzením data v cloudu = data v čoudu, není vůbec žádný rozdíl. Obojí je papouškování nesmyslů bez jakéhokoli pochopení situace.

5468
Odkladiště / Re:Zatopení hostingu Casablanca
« kdy: 25. 01. 2014, 10:16:37 »
100 % dostupnost je jednoznačně podvod. Ale co jsem tak zahlédl, oni v reklamě 100% dostupnost neměli – těch 100 % se vztahovalo k něčemu jinému. Tohle je podle mne chyba zákazníků – že jakmile někde v nabídce uvidí „100 %“, hned to chápou, že je to 100% dostupnost služby. I kdyby tam bylo napsáno, že 100 % pracovníků hotline jsou vegetariáni.

Co jsem pochytil v okolních diskusích, ta smlouva neslibuje míň, než ta reklama, a jediné, co je podstatné je, zda k výpadku došlo vinou Casablanca Inc. Viděl bych to na slevy po dobu nedostupnosti, případně „dobrovolné“ kompenzace „pokud si objednáte službu na další rok, dostanete měsíc zdarma“. Kompenzace za obchodní škody těžko, nezaznamenal jsem nic, co by nasvědčovalo tomu, že smlouva něco takového obsahovala.

Ne všechny služby lžou o 100 %. Některé uvádějí uvěřitelná nižší procenta. Viděl bych to tak na pět základní kategorií:
  • Reklama mluví o garanci 100 %, ve skutečnosti není garantováno vůbec nic. Nejlevnější řešení, je potřeba počítat s tím, že vám od začátku lžou – a je dobré zvážit, zda ta úspora stojí za to. Ale pokud si takhle někdo chce provozovat blog…
  • Reklama neříká nic o garanci, prostě jenom řeknou, jak často zálohují. Spolehlivost nebude nijak zázračná, ale aspoň vám nelžou.
  • Reklama mluví o 100 % (nebo méně), a znamená to, že v případě nedostupnosti vám vrátí poměrnou část za dobu, kdy to neběželo, nebo třeba nějaká procenta z měsíčního poplatku. Pozor na to, že to pořád není žádná garance a nic jasně definovaného.
  • Jsou uvedena procenta menší než 100 %, uvedené období, v jakém se to měří, a odkazuje se na SLA. Pokuty za nedostupnost nad povolená procenta jsou už citelné a provozovatele motivují, aby tu dostupnost zajistil. Ale hlavně SLA říká, jak přesně se ta dostupnost bude měřit. Pořád to ale není garance, že to skutečně poběží – akorát je přesně definováno, jak se to „běžení“ má projevovat, a provozovatel je silně motivován to zajistit.
  • Skutečná garance doložená auditem nebo certifikací nezávislou třetí stranou. Rozhodně to nezískáte na celé IT, jen na dílčí kritické komponenty typu zabezpečovací zařízení na železniční trati nebo na lokomotivě, bezpečnostní zařízení v elektrárně apod.

Geograficky vzdálená úložiště nejsou problém, běžně se to tak dělá. Pro zajištění vysoké dostupnosti ani nepotřebujete takovou vzdálenost. Ale jedna věc je mít data na druhém diskovém poli, a úplně něco jiného je být schopen nad tím spustit plnohodnotný provoz.

Cena, dostupnost, bezpečnost a použitelnost jsou spojené nádoby. Čím více do toho investujete, tím spíš se ubráníte. Ale jistotu nebudete mít nikdy, pořád hrozí, že někdo investuje ještě víc, aby tu ochranu prolomil.

Pokud má někdo SLA na cloud službu, bude tam třeba napsáno, že ze sedmi měřících bodů musí alespoň pět dostat do určeného času  správnou odpověď na požadavek. Což by v tomto případě samozřejmě nebylo splněno. Taky tam ale může být, že do určitého času dostane odpověď serveru, což klidně zajistí třeba statická HTML stránka nebo odpověď HTTP 500 od serveru. A data v databázi mezi tím mohou být nenávratně ztracená. Záleží na tom, jak je SLA napsáno. Na to je samozřejmě potřeba dávat pozor, protože vás zajímá, jestli můžete tu službu používat, nezajímá vás zda se točí disky nebo jde proud. Poskytovatel má zase přesně opačnou tendenci, garantovat napájení, konektivitu od něj k prvnímu bodu venku nebo dostupnost náhradního HW do x hodin pro něj není problém, ale garantovat dostupnost služby je už mnohem těžší.

5469
Odkladiště / Re:Zatopení hostingu Casablanca
« kdy: 25. 01. 2014, 08:18:23 »
Pokud existoval příslib nebo reklama na 100% dostupnost, je to na první pohled podvod. Jediné, co někdo dokáže opravdu garantovat,  je, že při dostupnosti menší než X, kde X je < 100 %, bude platit pokutu. A to tam ještě budou výluky, že se to nevztahuje na výpadky způsobené válkou, teroristickými akcemi ani živelními katastrofami.

Pokud si vyberete nějakého schopného poskytovatele cloudových služeb, budete mít daleko větší problém zajistit ten nepřetržitý provoz na své straně - garantované a zálohované připojení do internetu, zálohované napájení... Otázka samozřejmě je, zda poskytujete tak nepřetržité služby, aby pro vás třeba 2hodinový výpadek představoval vážný problém. Pokud ano, stejně musíte sídlit ve více lokalitách a mít to všechno tak zajištěné, že zajištění IT bude jen další položka na seznamu.

Výpadek cloudu v řádu dní by svědčil o vážné chybě provozovatele. Cloud je k celkovému výpadku nejnáchylnější v administraci, v tom systému, který řídí jednotlivé node, předává mezi nimi práci apod. Nekritičtější je aktualizace takového systému a provozovatel cloudu by měl mít plán, jak se v případě vážných problémů vrátit k předchozí verzi.

Další věc je, s čím to porovnáváte. U cloudu samozřejmě nemáte jistotu, že něco provozovatel totálně nezvoře a nebude mít několikadenní výpadek. Ale stejně tak tu nejistotu máte u interního IT. Pokud si opravdu žádný větší výpadek vůbec nemůžete dovolit, stejně byste i u interního IT musel mít nějaký záložní plán na způsob, že nejdůležitější data jsou zálohovaná někde úplně jinde, v případě havárie systému je dokážete jednoduchými prostředky vytáhnout a dát třeba do Excelu a nouzově pracovat aspoň s tím. A stejnou zálohu musíte mít u cloudu.

Každopádně vždy musíte mít zálohu dat. Skoro k ničemu je, pokud zálohu možná máte, ale nemáte to ověřené a nemáte popsaný (a vyzkoušený) postup obnovy. Je potřeba taky dát pozor na to, zda data dávají nějaký smysl i bez konkrétní aplikace (office dokumenty v nějakém rozšířeném formátu otevřete kdekoli), nebo zda k tomu bezpodmínečně potřebujete i aplikaci. No a dál už si můžete vybírat podle toho, kolik do toho chcete vrazit - zkracovat doby nutné pro kompletní obnovení provozu ze zálohy a zmenšovat pravděpodobnost nutnosti obnovy ze zálohy.

5470
Vývoj / Re:Jazyk podobný C#
« kdy: 21. 01. 2014, 13:51:03 »
pokud ale použiji StringBuffer
Protože to bezpečně běží v jednom vlákně, je špatně použití i StringBufferu se zbytečnou synchronizací, správné je použít StringBuilder. Ostatně javac to sčítání řetězců na StringBuilder přeloží, akorát že tady bude každé sečtení vytvoření samostatného builderu, spojení a zahození builderu – protože to kompilátor neodhalí, že by se to dalo celé udělat s jedním.

5471
Vývoj / Re:Jazyk podobný C#
« kdy: 21. 01. 2014, 09:57:24 »
Zase až tak mne nepodceňuj. Počítalo se to podobně jako u toho Mandelbrota. Viz:
Takže se měří jen doba provádění toho kódu, start JVM v tom započítán není a kompilace nejspíš také ne. To je řekl bych dost podstatné…

5472
Vývoj / Re:Jazyk podobný C#
« kdy: 21. 01. 2014, 08:10:06 »
Beželo to čtyřikrát, aby se JIT mohl "zahřát".
Čtyřikrát v rámci jednoho procesu? Jak to pak měříte, jak k tomu připočítáte čas startu JVM a kompilace? Pokud to bylo čtyřikrát spuštěno z příkazového řádku a tedy čtyři různé procesy, JIT se nijak „nezahřeje“ – při každém běhu běží znova od začátku. JIT si neukládá žádné informace mezi jednotlivými spuštěními aplikace, každé spuštění aplikace je pro něj poprvé. Opakované spuštění pomůže nejvýš tomu, že OS načte potřebné soubory do cache. Ale k tomu by mělo stačit spustit to dvakrát. A dělá se to tak u všech testů a první se neměří, protože doba načítání z disku nás zpravidla nezajímá. Nebo je možné to spouštět rovnou z RAMdisku.

5473
Vývoj / Re:Jazyk podobný C#
« kdy: 20. 01. 2014, 21:17:17 »
V tomto pripade bych zduraznil. JVM se dobre optimalizuji prave takove jednoduche smycky s par vyrazama (aritmetika, jednoduche operace s retezci). Daleko horsi to je u strukturovanejsiho nehomogenniho kodu s hlubokymi vnorenimi volanimi. Jinymi slovy tyhle mikrobenchmarky nic nevypovidaji o rychlosti behu "realnych" aplikaci. Puvodni autor zvolil teda hodne spatny priklad pro porovnani.
Jako benchmark jazyků je to rozhodně špatný příklad. Prohodit ten if a smyčku může kompilátor klidně na základě analýzy kódu, k tomu běhové informace nepotřebuje. A vůbec bych se nedivil, kdyby třeba icc tu smyčku spočítalo už v době kompilace a vygenerovalo jenom if se dvěma konstantama.

Spíš to ukazuje, že ten strašák "musí nastartovat JVM a přeložit kód" je nesmysl. A docela by mne zajímalo, co se vlastně změřilo - třeba jak moc by ta čísla byla jiná, kdyby se ta konstanta vydělila dvěma nebo by se naopak načítala dvě počítadla najednou.

5474
Vývoj / Re:Jazyk podobný C#
« kdy: 20. 01. 2014, 17:36:36 »
Java Elapsed 1.045
C/gcc Elapsed 0.96
C/icc Elapsed 0.90
Takže rozdíl mezi Javou a C je v tomto případě skoro stejný, jako rozdíl mezi dvěma kompilátory C. Na tom je vidět, jak nesmyslné je porovnávat programovací jazyky z hlediska rychlosti spuštěného kódu.

5475
Vývoj / Re:Jazyk podobný C#
« kdy: 20. 01. 2014, 16:00:34 »
Tvrdí, že Java potažmo libovolný JIT je rychlejší než C, protože má víc informací než C kompilátor.
Netvrdí. Tvrdí, že zpomalení způsobené překladem bajtkódu do nativního kódu může být kompenzováno nebo dokonce překonáno tím, že kód vytvořený JIT kompilátorem může být efektivnější, než kód vytvořený statickým kompilátorem při překladu ze zdrojového kódu.

Já se k Vám nemohu připojit, ano, JIT může vyhodit určitou část kódu, ale tu může vyhodit i překladač C a Java už z principu nemůže být rychlejší než dobrý C kód.
Jednak JIT může překládat kód pro platformu, na které právě běží. C kód je často překládán pro nějakou obecnou platformu, aby nebylo nutné distribuovat spoustu variant binárek. Za druhé, JIT má informace z běhu programu, které C kompilátor nemá. V případě C se to obchází tím, že se kód spustí v profileru, používá se typickým způsobem a podle toho se upraví zdrojový kód. Jenže typické způsoby použití se od sebe mohou lišit. Takže efektivní nativní kód jedné aplikace se může lišit podle způsobu použití. Opět by bylo možné přeložit C s různými optimalizacemi a uživatel by si vybral – ale jednak nikdo nemá čas něco takového vyrábět, jednak uživatelé si nechtějí z něčeho takového vybírat.

V teoretické rovině máte pravdu, že JIT nemůže být rychlejší, než ten nejefektivnější kód v C. Přinejhorším se v tom C dá naprogramovat vlastní VM s vlastním JIT kompilátorem. Prakticky se ale něco takového dělá jen velmi výjimečně a je snaha tyhle věci zobecňovat a dostat je už do vývojářských nástrojů (právě ty různé VM).

Ono porovnávat rychlost na CPU nemá moc smysl, ale když už se to dělá, porovnává se běžně napsaný kód jedním způsobem a druhým způsobem. Tedy žádná vlastní VM s JIT v C a žádné JNI v Javě. A v téhle praktické rovině platí, že zátěž, kterou způsobuje překlad bajtkódu, je oproti ostatním vlivům zanedbatelná.

Stran: 1 ... 363 364 [365] 366 367 ... 375