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 ... 206 207 [208] 209 210 ... 375
3106
Vývoj / Re:Placená Java SE?
« kdy: 06. 07. 2018, 13:09:49 »
Je to víceméně pořád stejné, jako to bylo dříve a jako to bylo už za Sunu. Je zdarma dostupná a podporovaná aktuální verze a nějaké starší verze, s placenou podporou pak můžete mít nějaká vylepšení a podporu pro starší verze. Akorát to dříve bylo jinak snad pro každou verzi, teď v tom Oracle konečně dělá pořádek – jednou za tři roky vydá Oracle LTS verzi s dlouhodobou podporou pro své zákazníky, LTS verze bude dostávat updatyaž do vydání následující LTS verze, resp. ještě nějakou dobu po něm. A vedle toho budou veřejné buildy OracleJDK, kde bude nová verze vydávána každého půl roku. Java 8 je teď ještě ve speciálním režimu LTS s dlouhodobou podporou, první standardní LTS verze bude 11, která vyjde na podzim. Mezi tím už vyšly verze 9 a 10, které ale nemají dlouhodobou podporu a po půl roce s verzí 9 se plynule přešlo na 10 a z 10 se na podzim plynule přejde na 11. Na jaře 2019 si pak budete moci vybrat, zda zůstanete jako placený zákazník na dlouhodobě podporované OracleJDK 11, nebo zda budete pokračovat s veřejnou OpenJDK 12. A tak dále.

3107
Software / Re:problem s letsencrypt na androide
« kdy: 06. 07. 2018, 12:41:59 »
Pridal som tam vsetky certifikaty
Kód: [Vybrat]
SSLCertificateKeyFile    /etc/letsencrypt/live/web/privkey.pem
SSLCertificateFile       /etc/letsencrypt/live/web/cert.pem
SSLCertificateChainFile  /etc/letsencrypt/live/web/chain.pem
SSLCertificateChainFile  /etc/letsencrypt/live/web/fullchain.pem
a stejne to pise, ze certifikat pochadza z nedoverihodnej autority
A to vám Apache takhle vezme? A jste si jist, že si to přebere správně? Proč to zbytečně komplikujete a nedáte tam přesně tu konfiguraci, kterou jsem vám napsal? Případně variantu, kterou napsal ByCzech – pokud jsou certifikáty v fullchain.pem správně seřazené.

Jaké certifikáty vám server vrací si můžete ověřit pomocí openssl s_client. Např.:

Kód: [Vybrat]
% openssl s_client -connect root.cz:443
CONNECTED(00000003)
depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
verify return:1
depth=0 CN = root.cz
verify return:1
---
Certificate chain
 0 s:/CN=root.cz
   i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
 1 s:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
   i:/O=Digital Signature Trust Co./CN=DST Root CA X3
---
Server certificate
-----BEGIN CERTIFICATE-----
[…]
Důležitá je ta část pod Certificate chain. Musí tam být dva certifikáty, 0 bude certifikát vašeho serveru (místo root.cz), 1 bude to samé, co je v tomto výpisu, protože root.cz také používá Let's Encrypt.

3108
Software / Re:problem s letsencrypt na androide
« kdy: 06. 07. 2018, 08:19:02 »
Apache potřebuje znát jak privátní klíč (který používá při šifrování spojení), tak certifikát a případně certifikační cestu (kterými se prokazuje klientovi). Takže SSLCertificateKeyFile musí ukazovat na privátní klíč, a dále SSLCertificateFile  na serverový certifikát (a mohou za něj být přidané mezilehlé certifikáty, v pořadí nejprve serverový certifikát a pak vždy certifikát, který byl použit k vystavení předchozího certifikátu v souboru), případně mezilehlé certifikáty mohou být v SSLCertificateChainFile.

Takže ve vašem případě:
Kód: [Vybrat]
SSLCertificateKeyFile    /etc/letsencrypt/live/web/privkey.pem
SSLCertificateFile       /etc/letsencrypt/live/web/cert.pem
SSLCertificateChainFile  /etc/letsencrypt/live/web/chain.pem

Nezapomeňte na to, že certifikáty Let's Encrypt mají platnost jen tři měsíce, takže je potřeba je často obnovovat, ideálně automaticky skriptem třeba z cronu.

3109
Software / Re:problem s letsencrypt na androide
« kdy: 05. 07. 2018, 12:41:25 »
Ako přibalit mezilehlý certifikát Let's Encrypt k certifikátu pro danou doménu
Záleží na konkrétním serveru. Např. nginx umožňuje uvést zvlášť cestu k serverovému certifikátu a zvlášť k mezilehlému certifikátu autority, nebo dáte všechny certifikáty do jednoho souboru a uvedete cestu jenom k němu. Certifikáty se do daného souboru prostě nakopírují za sebou, takže v souboru je pak:
Kód: [Vybrat]
-----BEGIN CERTIFICATE-----
… 1. certifikát …
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
… 2. certifikát …
-----END CERTIFICATE-----

3110
Vývoj / Re:Je utf8 univerzální?
« kdy: 05. 07. 2018, 09:23:29 »
nakonec existuji ruzne sady znaku a ruzne lokalni variace, ktere unicode/utf nepokryva nebo pokryva chybne. pouziva se misto toho ucs
Nesmysl, UCS má stejné znaky a k nim přiřazené stejné kódy, jako Unicode. Praktický rozdíl je hlavně v tom, že UCS kódování mají pevnou délku znaku – UCS-2 má dva bajty a UCS-4 čtyři bajty. UCS-2 tedy umí vyjádřit pouze základní (původní) Unicode sadu, čímž se liší od UTF-16, které základní Unicode sadu vyjadřuje také pomocí dvou bajtů, ale pomocí náhradních párů umožňuje zapsat i znaky mimo BMP.

3111
Software / Re:problem s letsencrypt na androide
« kdy: 05. 07. 2018, 09:11:07 »
Posílá server kompletní certifikační cestu, tj. všechny certifikáty s výjimkou kořenového? Certifikáty Let's Encrypt jsou podepsané ještě další certifikační autoritou, a některé starší systémy neznají přímo certifikáty Let's Encrypt, ale znají tu nadřazenou certifikační autoritu (DST Root CA X3).

3112
Vývoj / Re:Je utf8 univerzální?
« kdy: 04. 07. 2018, 20:32:40 »
Unicode pokryje všechny normální jazyky a písma na světě – přesněji na Zemi :-) UTF-8 je jeden ze způsobů serializace Unicode. Tedy to, co potřebujete, pokryjete vstupem v UTF-8. Např. JSON je podle standardu vždy UTF-8, takže nebudete první, kdo toto kódování určí jako jedinou možnost. I zmíněné japonské nebo čínské znaky jsou pokryté Unicode, např. japonská Wikipedia používá Unicode. Akorát není v těchto zemích UTF-8 tak populární, jako v Evropě a Americe, protože japonské nebo čínské znaky kóduje neefektivně, oproti jiným kódováním. UTF-8 tedy můžete použít.

3113
Vývoj / Re:Zjištění chyby při neúspěchu fwrite()
« kdy: 03. 07. 2018, 20:27:53 »
To je vtipná představa, že by junioři ve zkušební době (protože po zkušebce už musí takhle očividné chyby vidět sám) vyhazovali seniory, když by si senior dovolil upozornit na chybu v kódu juniora.

Ale je teda dost smutné vidět tu několik lidí, kteří si o sobě očividně myslí bůhví co a myslí si, že umí programovat, kterým nevadí program pro zápis do souboru, který:
  • úspěšně zapíše všechna data a vypíše chybu, že se podařilo zapsat jenom část dat
  • skončí s chybou, že se nepodařilo všechna data zapsat, přestože na disku je dost místa a ani nic jiného nebrání všechna data zapsat

Navíc kdyby ta funkce fwrite() uměla nějak signalizovat příčinu chyby, při zápisu na zcela plný disk by program správně oznámil, že disk je plný, ale kdyby se disk zaplnil teprve v průběhu zápisu, program by v lepším případě (pokud by andreaw.feana něco osvítilo a počítal by s tím, že se při zjištění chyby může dozvědět, že k žádné chybě nedošlo) oznámil, že došlo k nečekané chybě.

Stejně by mne ale zajímalo, kdyby L., ffd, BoneFlute nebo andreaw.fean odpověděli na ty tři otázky, které jsou v mém předchozím komentáři. Zajímalo by mne, jestli aspoň chápete význam jednotlivých řádků kódu, jenom si nedokážete spojit dohromady, co to dělá, když se ty řádky provádí postupně za sebou, a nebo jestli vám uniká i význam těch jednotlivých řádků.

3114
Vývoj / Re:Zjištění chyby při neúspěchu fwrite()
« kdy: 03. 07. 2018, 09:23:45 »
Je to tak. Pevně doufám, že nikde neprogramuje a pokud ano, tak lituju jeho spolupracovníky. U mě by takový nemehlo vyletělo na hodinu zavřenýma dveřma a ještě bych mu je dal k úhradě.
Dobře, uznávám, rozumíte tomu lépe než já. Můžete mi tedy některé věci na tom kódu uvedeném v dotazu vysvětlit? Napíšu i nijaké příklady možných odpovědí, aby bylo srozumitelnější, na co se ptám – těmi příklady odpovědí se ale nenechte zmást, ty jsou evidentně špatně.

  • Jaký je význam toho druhého volání fwrite() – na řádku 14? Myslím tím jakou situaci ošetřuje. Např. by odpověď mohla být: „Ošetřuje situaci, kdy první volání fwrite() na řádku 9 je jen částečně úspěšné, zapíše jen část dat, ale je možné, že se při dalším pokusu podaří zapsat další část – např. pokud by při prvním volání byl disk plný, ale před druhým voláním by se místo uvolnilo.“
  • V jakém případě dojde program k tomu druhému volání fwrite() – na řádku 14? Jaké budou invarianty programu? Např.: „První volání fwrite() na řádku 9 vrátilo hodnotu FALSE nebo 0.“ Nebo.: „První volání fwrite() na řádku 9 vrátilo hodnotu počet zapsaných bajtů, větší než 0 a menší než délka $s.“
  • Jaký bude výsledek volání programu, pokud před prvním voláním fwrite() (na řádku 9) bude na cílovém disku volné místo, ale ne tolik, aby se tam vešlo celé $s, a před druhým voláním fwrite() (na řádku 14) se nějaké místo na disku uvolní? Zajímá mne především co bude aplikace vypisovat a co bude zapsané v cílovém souboru.

3115
Vývoj / Re:Zjištění chyby při neúspěchu fwrite()
« kdy: 03. 07. 2018, 07:49:25 »
Nejdřív jsi se tu točil na nějakém částečném zápisu, což ale problém vůbec nebyl. Ono totiž PHP, jak se zdá, tu smyčku dělá už interně ve funkci, kterou volá ten fwrite(): https://github.com/php/php-src/blob/master/main/streams/streams.c#L1080
Normální je programovat proti specifikaci funkce, ne proti tomu, jak je aktuálně naimplementovaná. Když je zdokumentováno, že funkce vrací počet zapsaných bajtů, plyne z toho, že nemusí zapsat vše (zvlášť když je to obvyklé chování funkcí zapisujících do streamu). Když si někdo zjistí, že zrovna v jeho verzi ta funkce zapíše vše nebo vrátí chybu, naprogramuje podle toho svůj kód, a pak se chování funkce změní (ale bude pořád v souladu s dokumentací), bude mít v programu chybu, v tomto případě navíc těžko odhalitelnou (protože bude nastávat jen někdy).

Že ta PHP funkce fwrite() funguje úplně jinak, než je popsáno v dokumentaci, je dost zásadní chyba. Pokud to tazatel věděl, měl to napsat. Jinak bývá dobrým zvykem hledat chybu nejprve ve svém kódu a teprve pak v knihovnách. A ten kód andreaw.fean je špatně, a to i v případě, když bude počítat s tím, že tu smyčku dělá fwrite() interně.

Kdybys měl alespoň trochu ánunk o tom, o čem píšeš, tak by ti došlo, že posix_get_last_error() je z POSIX modulu, tedy funguje jen pro jeho funkce. Ty se vyznačují tím, že mají prefix posix_. No a jak si můžeš všimnout, funkce fwrite() ten prefix nemá. Takže na ni posix_get_last_error() logicky nefunguje a tedy to co jsi psal, je totální hovadina.
Dalo se předpokládat, že fwrite() interně volá nativní funkci write(), která je definovaná POSIX standardem, a která v případě neúspěchu ukládá chybový kód do errno. Funkce posix_get_last_error() mohl být způsob, jak errno přečíst.

Hele a tohle jsi v praxi ověřoval? Řek bych že ne a zase jen plácáš ty svoje neověřený teoretický nesmysly. PHP prostě žádný chybový kód nenastaví. Ani při prvním, ani při jakémkoli dalším volání.
Ten kód, tak jak je napsaný, nejdřív předpokládá, že když se nezapíše vše, je to hned chyba, a vzápětí se pokusí zapsat ještě zbytek. Při jaké konstelaci tenhle kód dává smysl?

Ověřit to chování měl andreaw.fean, on měl prostředí, kde k nějaké chybě docházelo. Když se mně nepodaří nasimulovat případ, že by fwrite() vrátilo menší počet zapsaných bajtů, než byl počet bajtů k zápisu, v žádném případě to neznamená, že mám počítat s tím, že to nemůže nikdy nastat. Přesně na základě takovýchto předpokladů vznikají programy, které pak různě náhodně padají.

To, že PHP žádný chybový kód nenastaví bylo potřeba zjistit – buď zkoumáním zdrojáků, nebo testem. Ten test je ovšem potřeba provést tak, aby vůbec byla šance, že tu chybu nastaví. Tvrdit, že funkce fwrite() chybu nenastavuje, na základě kódu, který nastavení chyby neumí zjistit, je dost odvážné. A nic na tom nemění fakt, že se nakonec (úplně jiným způsobem) ukázalo, že fwrite() opravdu chybu nenastavuje.

Kdyby se funkce fwrite() chovala tak, jak je popsané v dokumentaci, ten kód andreaw.fean by se choval přesně tak, jak popisoval – tj. žádnou chybu by to nevypsalo. Stačilo by ten kód opravit. Že se nakonec fwrite() chová úplně jinak je dost problém, a vzhledem k této diskusi je to jen náhoda. Kdyby andreaw.fean ten svůj kód opravil, vzápětí by se přišlo na to, že fwrite() funguje špatně – a mohlo by se to řešit. Místo toho se tu pořád dokola řešilo, že vlastně nikdo neví, jak vlastně ten kód funguje. Vždyť andreaw.fean ani nebyl schopen napsat, jestli mu to volání fwrite() vrací FALSE, 0 nebo nějakou kladnou hodnotu. To by hledání chyby značně urychlilo, protože kdyby opakovaně vracelo 0, bylo by jasné, že se to chová jinak, než je zdokumentováno.

Nakonec se tedy strašně dlouhou a klopotnou cestou skládání náhodných úryvků kódu dospělo k řešení, se kterým je andreaw.fean spokojen. Je ale velmi smutné, kolik lidí tady v diskusi vůbec nepochopilo, proč je ten původní kód špatně, a vlastně jim je úplně jedno, že to nechápou – prostě ten kód zkouší náhodnými výstřely měnit, a když jim to jednou udělá, co chtějí, jsou spokojení, a mají pocit, že je kód správně. A ještě mají pocit, jací jsou machři. Už se vůbec nedivím, že BoneFluteovi jednotkové testy vůbec nepomáhají – pokud testuje jenom to, co mu zrovna spadlo pod rukama, a vůbec nechápe, co jeho kód vlastně dělá a kde jsou potenciální chyby, jednotkové testy mu opravdu nijak nepomůžou.

3116
Vývoj / Re:Zjištění chyby při neúspěchu fwrite()
« kdy: 02. 07. 2018, 22:23:51 »
Na což se neptal, nesouviselo to s tím na co se ptal, a ani to nijak nepomohlo s jeho problémem. Rada na nic.
Vy jste stále ještě nepochopil, jaký problém se tu řeší. Takže vaše názory na to, co pomohlo a co ne, jsou k ničemu.

Což udělal, a podle jeho reakcí soudě vyzkoušel. Že tvrdíš, že to nevyzkoušel, že tvrdíš, že to nenapsal, přestože to má uvedené hned v prvním příspěvku - to už je tvůj problém. A tvá drzost.
Kdyby napsal výsledky toho pokusu, napsal by fwrite() zaplnilo disk a vrátilo v poslední smyčce 0 a posix_get_last_error() také 0, v druhém pokusu vrátilo po zaplnění disku error_get_last() hodnotu NULL. To by to ovšem nejdřív musel vyzkoušet, že… Kód v prvním příspěvku by mohl hlásit chybu zaplnění disku jedině v případě, že by disk byl plný už před začátkem zápisu. Kdyby se disk zaplnil už voláním té funkce fwrite(), selhalo by už druhé volání fwrite(), a tam žádný výpis chybového kódu není. Programátor to musí vidět na první pohled. Takže vaše snaha najít nějaký programovací jazyk, kde byste vůbec nemusel programovat, protože vám to nejde, je pochopitelná. A to ještě pořád nejsem drzý.

Jaký chování? Že není spokojený s radou, která prostě nefunguje? Když by se všichni chovali jako on, tak by bylo krásně na foru.
Jestli ta rada funguje nebo nefunguje by mohl zjistit teprve tehdy, až by ten kód opravil. Což se nestalo. Pokud nepochopil, v čem je problém, mohl se slušně zeptat. Což se také nestalo.

Víš, problém jsi tu ty, ne ostatní.
Můj problém je, že se tu vybavuju s někým, kdo si o sobě myslí, že je mistr světa, a přitom si ani neumí zavázat tkaničky. Pozdravujte Jéčko na ignorlistu.

3117
Vývoj / Re:Zjištění chyby při neúspěchu fwrite()
« kdy: 02. 07. 2018, 17:44:38 »
Být tebou Jirsák, tak mlčím a šoupu nohama, protože se právě ukázalo, že jsi tu celou dobu velkohubě radil hovadiny.
Mohl byste být přesnější, co z toho, co jsem radil, byla hovadina? Tazatel měl špatně napsaný zápis do souboru, to jsem mu poradil, jak opravit – ten původní kód by fungoval jedině tehdy, kdyby se jedním voláním fwrite() podařilo zapsat všechna data bez chyby. Ve všech ostatních případech by ten kód dělal nesmysly. Dále jsem tazateli poradil, že až si kód opraví tak, aby opravdu detekoval selhání fwrite(), ať vyzkouší, zda přesnou chybu nezjistí z funkcí posix_get_last_error() nebo error_get_last(). Že to doteď tazatel nevyzkoušel nebo nenapsal výsledek toho pokusu, za to nemůžu. A povinnost zkoušet to za tazatele fakt nemám, už tak dostal mnohem lepší rady, než by si svým chováním zasloužil.

3118
Vývoj / Re:Zjištění chyby při neúspěchu fwrite()
« kdy: 02. 07. 2018, 16:55:02 »
Druhý sofistikovaně teoretizuje z manuálu, zdrojáku, ale že by ho napadlo si svoji radu prakticky vyzkoušet, to ne. Udělal jsem to tedy za vás.
Udělal jste to za tazatele. Když má spoustu blbých keců a ani neumí napsat, co vyzkoušel, nemíním si kvůli němu ještě instalovat PHP a něco zkoušet.

3119
Vývoj / Re:Zjištění chyby při neúspěchu fwrite()
« kdy: 02. 07. 2018, 14:42:22 »
Tak já myslím, že se od Filipa Jirsáka kromě siláckých řečí nic zajímavého nedozvím. Všechno mu to musím vysvětlovat po lopatě a nic z toho.
Dozvěděl jste se, kde máte v kódu chybu, proč je to chyba a jak jí opravit. Vysvětlovat jste nic nemusel, naopak jste na mnohé dotazy odpovídal až na několikátý pokus, případně vůbec. Vaše „výsledek stejný“ má k vyčerpávajícímu popisu chyby opravdu velmi daleko – i mnozí uživatelé chápou, že musí napsat, co přesně dělali a jaký byl výsledek. Pro programátora by to měla být úplná samozřejmost.

3120
Vývoj / Re:Zjištění chyby při neúspěchu fwrite()
« kdy: 01. 07. 2018, 07:58:43 »
Zapsání nula bytes chyba je
To je napsané kde?

Když se podíváte na ty příklady v manuálové stránce explain_write, neúspěšný zápise se tam rozpoznává tak, že návratový kód je menší než nula. Myslíte, že to v té manuálové stránce je špatně?

Jak jsem psal výše, něco takového by vedlo k busy loop a nesmyslnému aplikačnímu kódu.
Ne nutně. Nikdo netvrdí, že když write() vrátí nulu, musí ji vrátit i v příštím cyklu – v příštím cyklu už může být zápis úspěšnější a zapíše alespoň něco, nebo už se alespoň bude vědět příčina chyby a write() vrátí chybu plus třeba EAGAIN.
 write() může skončit úspěšně i v případě předchozí chyby, proto tam ty chybové kódy jsou, aby se aplikace mohla rozhodnout, co má zkusit znovu a jak (EAGAIN, EINTR, ENOSPC).

Na druhé straně je třeba říct, že dokumentace (citace je z Linux man page, nikoliv POSIX specifikace) by mohla být napsaná jasněji
V té manuálové stránce je jasně napsáno, že i při úspěšném volání se může vrátit nula. Ale mohlo by tam být explicitně napsáno, že se pak má volání opakovat, stejně jako pro jiné případy,když nebylo zapsáno vše. Dokumentace k jiným knihovnám tu nulu často neřeší vůbec.

V POSIX specifikaci jsem také nenašel nic o tom, že by nula byla chyba.

Stran: 1 ... 206 207 [208] 209 210 ... 375