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 - kotelgg

Stran: 1 ... 3 4 [5] 6 7 ... 15
61
Studium a uplatnění / Re:Aktuální MD rate pro korporáty
« kdy: 06. 05. 2021, 17:49:42 »
Ano, tak to chodí. Schopní živí neschopné. Je otázka, zda bychom to chtěli jinak a řešit třeba nemocné lidi stylem: nemáš peníze, tak jdi umřít do lesa.
I kdyby nějaká vláda chtěla udělat spravedlivější systém, vzít "neschopným" peníze a nechat je "schopným", vydrží to maximálně 1 volební období (neschopní přehlasují schopné).
Dle mě ale v tomhle vůbec není hlavní problém, protože evidentně to nějak funguje (kdo chce, tak jezdi autem za mega, vydělá na barák atd.). Problém je mrhání peněz na nesmysly a zatuhnutí na klíčových projektech. To by se musel od základu předělat systém řízení státu. Ne jako teď, že třeba u nás se každý rok mění ministr dopravy, ministr zdravotnictví 5x ročně apod.. Než zjistí, kde je záchod, tak nastupuje další. Po 80ti letech se dělá rekonstrukce dálnic a rozšiřuje se o 1m ?! Důvod, proč nešlo udělat další pruh, je, že by se to za jedno volební období nestihlo vyřídit. Tak to je asi něco špatně.

62
Server / Re:Router a Server v jednom
« kdy: 04. 05. 2021, 22:23:59 »
(...) je to myšlení hazardního hráče, který je přesvědčený, že když na ruletě padla 10x za sebou červená, tak příště už musí přijít černá - a nechce uvěřit, že šance je stále 18:37, stejně jako při prvním roztočení. Šalba vlastní zkušeností je nebezpečná.

Nikoli! Pravděpodobnost že padne červená v jednotlivém kole sice zůstává stále stejná, ale celková pravděpodobnost, že alespoň v jednom kole padne červená, roste s rostoucím počtem pokusů (= sčítání pravděpodobností).

Aplikováno na téma dotazu: Každého nakonec hacknou.

Přesně tak. Popisuje to třeba Poissonovo rozdělení:
https://cs.wikipedia.org/wiki/Poissonovo_rozd%C4%9Blen%C3%AD
V roce 1943 padla 32x po sobě červená, což je nejdelší zaznamenaný rekord (nebo spíš švindl). Kdyby se to neřídilo žádným pravidlem, tak padne klidně 100x, ale to se zkrátka neděje. 


63
Hardware / Re:Výběr telefonu - jak si vybrat správný model
« kdy: 02. 05. 2021, 17:15:34 »
https://www.indiegogo.com/projects/astro-slide-5g-transformer#/
[/quote]

Normálně kupuju mobil, až když se starej rozbije, ale myslím, že se mu tenhle měsíc stane "nehoda".

64
Zásadní otázka je, jestli by ho to bavilo. Pokud doteď moc nebo vůbec neprogramoval, tak k tomu třeba ani nemá vlohy. Osobně dělám cca 25% IT, 25% elektro, 50% programování a to mi vyhovuje. Když jsem programoval nějaký projekt 3 měsíce v kuse, tak to bylo na palici.

65
Udělat VLAN (přiřazení VLAN tag na KVM) pro VMs, co nemají vidět dovnitř. VMs se stejným tagem mohou komunikovat, s jiným nebo žádným ne.
Na routeru se to musí ještě nějak pořešit.

Sorry, pil jsem  ;D


https://elkano.org/blog/vlan-tagging-on-linux-for-kvm/

66
Server / Re:MariaDB - Galera - multimaster
« kdy: 16. 04. 2021, 20:20:10 »
Používám 2 roky na produkci a bez problému (eshop, mód rsync). Problém s transakcemi jsem nezaznamenal a to jich mám v aplikaci spoustu. Mám otestováno, že commit a rollback fungují dle předpokladu.

S myisam to nefunguje, to je jasně dané v základních požadavcích, ale proč by měl někdo používat něco jiného než innodb? Rychlost myisam je komická.

Pro hodně zápisů je lepší vyhradit 1 node (typicky pravidelné aktualizace cen a skladů u velké části položek najednou). Nebo když php posílá požadavky na db, tak aby v rámci jedné session probíhaly jen na jednom node (to mi řeší haproxy).
Testoval jsem výkon na čtení/zápis, kde dojde ke zpomalení synchronizace při extrémním zatížení (asi 1000x vyšším než reálně na produkci a to nedovolí haproxy) a pak se to může třeba hodinu vzpamatovávat, ale k poškození dat nedošlo.
Zásadní problém je nutnost hlídat místo na disku, protože když dojde na jednom nodu, tak se zastaví celý cluster (když node restartuju natvrdo, tak se nic nestane a vše běží dál a i následná synchronizace je okamžitá). Ono je to dobré hlídat tak jako tak nějakou automatikou.
Se ztrátou dat jsem se zatím nesetkal nebo že by na jednom nodu byla jiná data než na druhém. Vzhledem k množství položek na eshopu (200 000+) by se jakákoli chyba rychle projevila (eshop trestá každou chybu, když jsou všechny produkty na srovnávačích a na straně databáze problém ještě nebyl).

Takové rady na začátek jsou asi:
-vyzkoušet různé scénáře pádu serverů - 1 node ze 3, 2 ze 3, 3 ze 3 a zapsat si, co dělat u každého scénáře (když se něco podělá, tak každý node má log transakcí mezi nody, takže ví, co se dělo naposled a do konzole vypíše, že má třeba starší data)
-vyzkoušet si zálohu/obnovu přes mysql/mysqldump
-vyzkoušet si obnovu ze snapshotu celého node (pokud je to na ZFS nebo BTRFS, kde se snapshot jeví pro db jako výpadek napájení, z čehož by se měla bez problému vzpamatovat)

Vzhledem k tomu, že se jiné než očekávané problémy neobjevily, tak jsem zatím nic dalšího řešit nemusel. Další projekty připravuji už jen pro galera cluster.

67
Software / Re:2D designer elektroinstalace - co používáte
« kdy: 15. 04. 2021, 08:11:20 »
Na jednoduché jednorázové věci s popisky je nejlepší tinycad. U těch ostatních jsem x hodin zjišťoval, jak udělat čáru apod..

68
/dev/null / Re:Práce pro české společnosti
« kdy: 01. 04. 2021, 20:46:48 »
IT ve státě funguje stejně jako všechno ve státě. Česká pošta udělala v roce 2017 API (do té doby jste seznam expedic předávali na disketě). Ne, že by se podívali, jak to mají ostatní dopravci, ale prostě si ho navrhli sami od nuly. Po nasazení do provozu v něm chyběly základní věci a fungování zcela postrádalo logiku, která je pro eshopy běžná (dle ní se všechny objednávky balí 5 minut před předáním řidiči). Jako snad první eshop, který API nasadil, jsem jim psal připomínky, že by bylo dobré, kdyby šlo balíky posílat i jednotlivě a další věci. V emailu mi v klidu napsali, že pošta si API dělá sama a tomu odpovídá i rychlost jejich IT. Možná za půl roku se na to podívají. Další rok už jsem od jejich IT nedostal odpověď (dovolená). I tak mají API jedno z těch lepších, když vynechám, že by snad bylo snažší udělat jim nové než se napojovat na to jejich (tady se někdo řídil heslem: proč to dělat jednoduché, když to může být složité a programátor nad tím může strávit týden navíc).

69
Jsou i blockchainy, které průběžně ukládají zůstatky v každé transakci. Nevím tedy už které, zajímalo mě to spíš v roce 2018, kdy jsem chtěl udělat burzu. Dopodrobna jsem se zajímal o fungování bitcoinu, monera a iota. Iota vypadala jako nejvíc revoluční z hlediska téměř instantních transakcí, které vyžadují minimální výkon k potvrzení a šlo k tomu využít levné čipy za pár desítek korun.

70
/dev/null / Re:Práce pro české společnosti
« kdy: 31. 03. 2021, 22:45:53 »
Život je krátkej, pracujte míň, bavte se víc  :D

71
/dev/null / Re:Jak jsem (ne)kupoval hardware
« kdy: 29. 03. 2021, 12:44:28 »
To samé bylo ve 2017. Stačí chvíli počkat a bude spousta karet za babku.

72
Studium a uplatnění / Re:Jak začít programovat od nuly?
« kdy: 25. 03. 2021, 10:20:42 »
1. nauc sa dobre anglicky

Proč?

73
Hardware / Re:Doporučte stolní multimetr
« kdy: 22. 03. 2021, 09:30:34 »
Fluke vyrábí variantu svého multimetru s cenovkou 8-10k pro čínu za 1200-1400 Kč
Tipuju, že Fluke o tom nic neví :) Číňan prostě vyrobil pár noname kusů pro prodej bokem jako to normálně dělají.

74
Hardware / Re:Doporučte stolní multimetr
« kdy: 20. 03. 2021, 21:58:37 »
"Měřáky za 100 z kauflandu jedině pro nízké napětí."

chyba, samozřejmě malé napětí (do 50V), 1000V by s tím měřil jen masochista

75
Hardware / Re:Doporučte stolní multimetr
« kdy: 20. 03. 2021, 21:48:07 »
1 multimetr stejně většinou nestačí. Třeba tohle je takový univerzál: https://www.gme.cz/digitalni-multimetr-rlc-proskit-mt-5211

Na ostatní věci už se kupuje specializovaný měřák.

Měřáky za 100 z kauflandu jedině pro nízké napětí. Určitě neodpovídají dnešním normám pro běžné síťové napětí (jakože vás to může zabít). Nehledě na to, že ani napětí neměří správně.

Stran: 1 ... 3 4 [5] 6 7 ... 15