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 ... 304 305 [306] 307 308 ... 375
4576
Windows a jiné systémy / Re:Obcházení nastavení v hosts
« kdy: 01. 03. 2016, 15:53:29 »
Trvejte si, na čem chcete. Ale když v tom má tazatel kvůli matení pojmů trochu hokej, pak je to vysvětleno, jak je to doopravdy, a vy pak přijdete s tím, že v tom znovu začnete dělat hokej, není to zrovna chytré.

V unixových systémech to není v knihovní funkci v operačním systému, je to ve standardní knihovně C. Jak je to u Windows nevím, pokud je součástí OS i prohlížeč, může být jeho součástí i standardní knihovna C. Zrovna ty webové prohlížeče myslím knihovní funkce nepoužívají, protože s DNS potřebují dost agresivně kouzlit kvůli rychlosti načítání stránek.

4577
Gentoo bývalo kdysi jednou z nejlépe zdokumentovaných distribucí. Pak někdo dostal nápad, že bude dobré použít XML.  ::) ::) ::)
Dokumentace Gentoo byla na XML postavena od začátku, možná už z doby, kdy to ještě byl Enoch.

4578
Windows a jiné systémy / Re:Obcházení nastavení v hosts
« kdy: 01. 03. 2016, 15:24:24 »
Jedná se o velmi účinné a přitom nenáročné blokování na úrovni operačního systému
Nejedná se o blokování a není to na úrovni operačního systému. V příspěvcích před vámi bylo myslím dostatečně vysvětleno, jak to funguje.

4579
Jeste budu muset zjistit, v jakym stavu je XSL-FO, jestli je to pouzitelny.
XSL-FO je standard, je použitelný od začátku a aktuální verze je 1.1, takže se na něm nic zásadního neměnilo. Možná myslíte spíš implementaci – ta je v OSS prakticky jen jedna a to Apache FOP. Jeho vývoj dlouho stagnoval a FOP měl podivné mouchy, pak se pár vývojářů vzchopilo a vydali verzi 1.0, která už je použitelná bez nějakých tanečků okolo, ale vypadá to, že od té doby vývoj zase usíná.

4580
Server / Re:Jak zabránit harvestování WWW?
« kdy: 29. 02. 2016, 17:31:57 »
robots.txt? To je ten stahovač tak blbý, že ho respektuje?
Právě naopak, tazatel chce detekovat, že stahovač robots.txt nerespektuje.
Coz je slepa cesta. Stahovac se na robots.txt vysere, to respektuji leda tak slusne vyhledavace a podobne, ale urcite ne zlodeji.
Copak jsme to napsal tatarsky?

4581
Server / Re:Jak zabránit harvestování WWW?
« kdy: 29. 02. 2016, 16:46:49 »
robots.txt? To je ten stahovač tak blbý, že ho respektuje?
Právě naopak, tazatel chce detekovat, že stahovač robots.txt nerespektuje.

4582
Zkuste se podívat na XML Author. Je tam podpora pro DocBook i XSLT a FO. Pro XML/XSLT/XSD je to docela schopný editor, třeba bude dobrá i podpora DocBooku.

4583
Server / Re:Harvestování WWW
« kdy: 29. 02. 2016, 09:49:57 »
Musi ti byt jasny, ze to reseni nema.
Řešení to samozřejmě má. Není nutné kopírování technicky zabránit, stačí to natolik zkomplikovat, aby se to nevyplatilo. Zároveň hrozí, že při té obraně odříznete nebo naštvete legální uživatele.

4584
Vývoj / Re:komprese js a css v html - komplikovaný případ
« kdy: 28. 02. 2016, 23:21:13 »
Komprese celé stránky pomocí algoritmů LZxx asi nepřinese takový výsledek, protože to bude muset být v base64.
Nevím, proč by to muselo být v base64. Ale hlavně je vám komprese celé stránky pomocí LZxx k ničemu, protože jediný způsob, jak to v prohlížeči dekomprimovat, je JavaScript, který by byl součástí té stránky.

4585
Vývoj / Re:komprese js a css v html - komplikovaný případ
« kdy: 28. 02. 2016, 08:34:08 »
Reálné řešení je ty soubory vystavit někde na internetu a odkazovat na ně.

V HTML žádná dekomprese dat standardizována ani implementována není, takže si jí jedině můžete sám naprogramovat v JavaScriptu. Vzhledem k tomu,že všechny běžně používané kompresní algoritmy mají na vstupu i na výstupu binární data, nemůžete je přímo použít, protože do HTML přímo binární data nedostanete – musel byste je zase nafouknout base64, stejně jako ten obrázek. Takže lepší bude nějaký kompresní algoritmus si upravit tak, aby na výstupu používal znaky povolené v HTML. Ideální bude, když pro HTML použijete nějaké jednobajtové kódování (takže pro češtinu nejspíš ISO-8859-2) a pokusíte se pro kompresi využít maximální množství dostupných znaků.

Ovšem pokud tam nepřikládáte nějaké velké soubory, pochybuju, že dokážete napsat dekompresní funkci, která bude menší, než rozdíl nekomprimovaných a komprimovaných dat. Takže zbývá možnost, že soubory „zkomprimujete“ změnou jejich obsahu – JavaScriptové funkce a proměnné budete pojmenovávat jedním písmenem, stejně tak ID elementů pro CSS (a třídy nahradíte ID). Případně hledejte „javascript minification“ pro další triky, které můžete použít na zmenšení JavaScriptu.

4586
Server / Re:Načítání webu; problém DB?
« kdy: 28. 02. 2016, 08:18:11 »
S DB dělám už řadu let. Snažil jsem se změnit, přidat Primární klíč:
Kód: [Vybrat]
CREATE TABLE id (id INT AUTO_INCREMENT, PRIMARY KEY (id)); 

Avšak žádná změna. Pokračuji v hledání možností dál...
Možná jste se snažil přidat primární klíč, ale ve skutečnosti jste vytvořil novou tabulku. Já jsem vám psal, že jen tak si hrát s databází, když nevíte, co děláte, není dobrý nápad. Ještě pár pokusů, a budete mít po problému, protože si tu databázi smažete…

4587
Server / Re:Načítání webu; problém DB?
« kdy: 27. 02. 2016, 18:03:53 »
Pokud se nezapočítá zobrazení již navštívené stránky, ale započítá se až při vynuceném obnovení, je to nějaký problém s kešováním stránek a s databází to vůbec nesouvisí. „Přestalo fungovat přidávání komentářů“ může být způsobeno asi tak milionem věcí. Primární klíč v databázi znamená, že jednotlivé řádky v tabulce musí mít v dané položce unikátní hodnotu, a dále to, že tento sloupec představuje identifikátor dané entity a obvykle se používá, pokud na danou entitu chcete odkázat z jiné tabulky. Primární klíč se nastavuje jedním jednoduchým SQL příkazem, který v případě, že sloupec obsahuje duplicity, skončí chybou, jinak vytvoří primární klíč. Pokud ten příkaz neznáte nebo nevíte, kde byste ho v dokumentaci hledal, nepokoušejte se to spravit sám a najděte si někoho, kdo tomu rozumí a udělá to. Jinak napácháte víc škody než užitku. To samé s tím počítáním přístupů a přidáváním komentářů. Zjevně je někde uvnitř systému nějaká chyba, na kterou ale nepřijdeme tak, že budete popisovat vnější projevy, bez znalosti toho, jak to uvnitř funguje.

4588
Vývoj / Re:Poradíte s implementací Provably Fair?
« kdy: 27. 02. 2016, 17:42:17 »
To je reakce na mě nebo na koho? O nic takového se přece nesnažím.
To je reakce na tazatele.

Ale vždyť přesně tohle píšu. Když předpokládám maximálně 256 lístků a vygeneruju si 32b náhodné číslo, tak mám dost bitů na 4 pokusy po osmi bitech. V každém pokusu může být maximálně cca 1/2 ppost, že nevyhraje nikdo -> celkově je ppost, že nikdo nevyhraje (1/2)^4. Pokud se mi to zdá moc, použiju místo 32b víc. Nikdy se nedostanu na nulu, ale můžu se dostat na číslo, který jsem ochotnej akceptovat - a akceptuju možnost, že někdo nevyhraje, NEakceptuju nespravedlnost.
S vámi nepolemizuju, píšeme oba to samé :-) Akorát se snažím to samé popisovat jiným způsobem, protože přesný výpočet pravděpodobnosti je zjevně něco, čím se tazatel nenechá vykolejit ze svých „prostě“. Jinak 32 bitů je hezké číslo, ale podle těch čísel, co tu tazatel píše, se pohybujeme o několik řádů výš. A tam už zase může být problém dostat tolik „náhody“ dostatečně rychle.

4589
Vývoj / Re:Poradíte s implementací Provably Fair?
« kdy: 27. 02. 2016, 17:31:00 »
Pripad NEvylosovania sa da predsa osetrit ale hlavne - je menej problematicky ako "NEFEROVOST".

Ošetřit se dá všechno možné. To, jestli je to přijatelné a jestli je to méně problematické, než neférovost, je součást zadání – proto jsem se ptal, jaké přesně je zadání.

- Dam si vygenerovat 150 CHAR dlhy string 0 a 1 (1,4 x 10 na 45!)
- Pevna dlzka preto aby zaciatok mohol byt 00001.... a nuly sa mi nestratili
- 500 CHAR 0 a 1 mi pokryje naprikald: 0 az 1000 000 000 000 (bilion) celkovo 1,4 x 10 na 33!
Teda tohle rozluštit… 45! neznamená 45 faktoriál, ale prostě jen 45, aha. Psal jste o deseti miliardách, pro jejich pokrytí potřebujete 234. Z těch 150 bitů tedy uděláte (150/34=) 4 kola losování.

Takze vdaka tomuto mozem rolovat extremne vela krat, sanza ze by to stale nepadlo je MINIMALNA a pre mna nedolezita - lebo sa to proste nestane. Mat tak vela '1' vedla seba je nahoda tak mala ze ju mozem zanedbat.

4 kola losování, to podle mne není „extrémně vela“. Jak psal Mirek Prýmek, pravděpodobnost, že v jednom kole nikoho nevylosujete, je 1/2. Za čtyři kola tedy ta pravděpodobnost bude 1/24, tedy 1/16. To není minimální pravděpodobnost, to je sakra vysoká pravděpodobnost. Když se to bude hrát 16 hodin denně a každou hodinu se bude jednou losovat, jednou denně nikdo nevyhraje.

- nahodny generator cisel pouzivame HW samozrejme
To je fajn, ale uvědomte si, že budete mít hodně velkou spotřebu náhodných čísel. Abyste měl slušnou pravděpodobnost, že vám ta čísla nedojdou, potřebujete zásobu na desítky opakování, takže nepočítejte se 150 bity, ale s tisíci až desetitisíci bitů.

- stale nevidim problem ani v overeni toho stringu nejakym sposobom (napriklad : je tam 0?) a ak nie je tak pevnaDlzka +1 a dam dalsie nahodne cislo, a znova - je tam 0? a Znova a znova? Takze je to nahodna postupnost 0 a 1 ktora ma urctu vlastnost - takze by som mohol dokonca aj ten pripad jednotiek ( 1...11111...1) eliminovat uplne nie?
To vaše „ověření“ znamená, že byste vyházel hodnoty, které se nemohou použít. Jenže které hodnoty nepřipadají v úvahu víte až v okamžiku, kdy víte, kolik se prodalo lístků. Pokud byste eliminoval třeba ty „samé jedničky“, způsobíte, že při prodeji počtu lístků, který odpovídá mocnině dvou, nemůže ten poslední kupující vyhrát (protože jeho číslo odpovídá právě těm samým jedničkám). To nevypadá moc férově… To, že vám číslo skládající se binárně ze samých jedniček připadá zajímavé, je jenom klam – z hlediska pravděpodobnosti je úplně stejně pravděpodobné, jako kterékoli jiné číslo.

A to je na tom celém to nejdůležitější. Pokud chcete ten systém mít opravdu 100% férový, musíte opravdu dobře vědět, co děláte, jaké jsou charakteristiky komponent, které používáte, jaké mají předpoklady. A všechny ty pravděpodobnosti (např. jak často nikdo nevyhraje) si pak můžete velice snadno spočítat. Pokud to budete brát takhle intuitivně, že čísla 2n jsou nějaká divná a můžete je vyškrtnout, a nějakou pravděpodobnost intuitivně odhadnete na „prostě nestane“ (a ono je to pak 1/16), nebude ten váš systém férový ani omylem.

4590
Vývoj / Re:Poradíte s implementací Provably Fair?
« kdy: 27. 02. 2016, 15:37:33 »
Tak ako to chapem vidim jediny problem dlzku retazca 0 a 1 ale ta nech je klidne dlha veeeelmi :-) alebo problemu ze by bola cela rada len 1 a teda 'generovane' cislo by bolo vzdy vacsie ako limit N. Ale to nepredpokladam :-)
Nejen celá řada jedniček, ale prostě čísla, která jsou větší, než počet prodaných lístků. Sice to „nepředpokládáte“, ale to je přesně ta pravděpodobnost, že nikdo nevyhraje, o které psal Mirek Prýmek (a která se s prodlužováním předem vygenerovaného náhodného čísla limitně blíží nule). Takže pokud vám nevadí, že existuje nenulová pravděpodobnost, že nevyhraje nikdo…

Stran: 1 ... 304 305 [306] 307 308 ... 375