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 ... 291 292 [293] 294 295 ... 303
4381
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ě.

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

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

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

4385
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ěžší.

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

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

4388
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é…

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

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

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

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

4393
Vývoj / Re:Jazyk podobný C#
« kdy: 20. 01. 2014, 13:58:00 »
Až Tišňovský napíše, že JIT poskytuje takové optimalizace, které obecně překonávají rychlost stejně dobrého kódu napsaného v C++,  nezačnu tomu hned věřit, ale prohlídnu si jeho argumenty.
Nikdo tady nepíše o tom, že by nějaké optimalizace obecně překonávaly nějakou rychlost. Na vyvrácení tvrzení, že Java musí být vždy pomalejší, úplně stačí, když ty optimalizace budu lepší v některých případech.

Jinak od pana Tišnovského zrovna vychází na Rootu seriál o JVM, kde se optimalizacím věnoval. A byly tam i příklady srovnání kódu z JIT a z gcc.

4394
Vývoj / Re:Jazyk podobný C#
« kdy: 20. 01. 2014, 09:57:24 »
Nejlepší informaci o tom, co se bude dít, má autor kódu. Pokud ji neumí nebo nechce použít, měl by místo matlání kódu jít dělat něco užitečného.
Nesmysl. Software se často používá úplně jinak, než autor zamýšlel. I když se používá tak, jak bylo zamýšleno, používá se různým způsobem.

Proč by třeba Linuxové jádro mělo tolik konfiguračních voleb, když podle vás mají jeho autoři nejlepší informace, co se bude dít? Když už jsme u jádra, tam bylo také dost případů, kdy autoři ručně vynucovali nebo zakazovali nějakou optimalizaci, která byla špatně a kompilátor by to udělal správně. Kdyby všichni ti matlalové kódu šli dělat něco jiného, zbyl byste na celém světě na programování jen vy a možná pár dalších supermanů, kteří programují tak, že mají otevřeno několik desítek terminálů, a tam píšou rovnou nativní instrukce optimalizované pro konkrétní procesor. Jak byste zvládli všechen ten software napsat?

4395
Software / Re:Program na fulltext vyhladavanie v PDF
« kdy: 19. 01. 2014, 13:48:51 »
Apache Solr nebo další nadstavby nad Lucene.

Stran: 1 ... 291 292 [293] 294 295 ... 303