Příspěvky

61

Windows a jiné systémy / Re:Soubory TEMP nejsou ve Windows 10 odstraněny!

« kdy: 10. 08. 2021, 14:03:44 »

On se najde samovolně, až jednou z tempu odmaže soubory, které budou patřit k nějakému pending procesu, který je potřebuje mezi restarty.

Vždy mě fascinuje, jak si jednotlivec přidělává zbytečné problémy v přesvědčení, že tohle v Microsoftu jen ještě nikoho nenapadlo řešit.

Jinak postup, jak se zbavit starých souborů, které tam mohou zbýt po nějakém procesu, který po sobě neuklidí (typicky když skončí chybou a nemá to ošetřené), je jednoduchý – seřadím soubory podle data vzniku a smažu ty, které jsou starší než třeba jeden týden nebo jeden měsíc (záleží na tom, jak často vypínám počítač, nebo zda ho jen uspávám). Tím se prakticky na nulu sníží riziko, že smažu souboru pod rukama nějakému procesu, který ho potřebuje.

Mimochodem, slušné programy tuhle kontrolu dělají samy. Např. pokud Altap Salamander při startu najde v tempu jím vytvářené dočasné soubory, zeptá se, zda je má smazat.

Já především zjistil, že ani po několika letech provozu tam nejsou sedimenty, které by stálo za to řešit jinak, než standardním nástrojem Vyčištění disku.

62

Windows a jiné systémy / Re:Soubory TEMP nejsou ve Windows 10 odstraněny!

« kdy: 10. 08. 2021, 11:55:23 »

Děkuji všem za pomoc. Každopádně jsem byl schopen problém vyřešit podle následujících kroků.

Takže už známe řešení problému, teď už zbývá jenom k tomu řešení najít vhodný problém…

On se najde samovolně, až jednou z tempu odmaže soubory, které budou patřit k nějakému pending procesu, který je potřebuje mezi restarty.

Vždy mě fascinuje, jak si jednotlivec přidělává zbytečné problémy v přesvědčení, že tohle v Microsoftu jen ještě nikoho nenapadlo řešit.

63

Windows a jiné systémy / Re:Soubory TEMP nejsou ve Windows 10 odstraněny!

« kdy: 09. 08. 2021, 20:51:44 »

Nedávno jsem narazil na vážný problém. Soubory TEMP nejsou ve Windows 10. trvale odstraněny. Setkal se někdo s podobným problémem již dříve? Pomozte, pokud je to možné.

A jaký je problém? Nějaká obsese, že se to má čistit, nebo to něco skutečně způsobuje?

64

Server / Re:Výměna disku v RAID 6 ve stavu Repairing?

« kdy: 27. 07. 2021, 09:13:38 »

Teoreticky ano, ale prakticky se dostanete do bodu, kdy už jedna další závada znamená velké problémy.
Moc bych to nedoporučoval. Moje zkušenost je, že při synchronizaci raidu se právě objevují další problémy na ostatních discích, a může to být smrtelná spirála pro data.

65

Studium a uplatnění / Re:Rozdíl mezi ohodnocení na MD vs hodinové

« kdy: 24. 07. 2021, 07:12:32 »

Hlavní účel je v tom (ale není vždy dodržován), že některých lidí si ceníte tak, že jejich práci nenabízíte po hodinách, ale po dnech, nebo aspoň půldnech. Drahý je context switching, a prodávat po hodinách je nevděčné.

Za MD nechtějí programátoři víc, ale jedná se právě o ty cennější, kteří mají celkově drahou práci.

66

Odkladiště / Re:Omezení pokusů pro přístup

« kdy: 23. 07. 2021, 15:17:22 »

Neexistuje na to vzorec. Úplně jinak asi budete chránit přístup v televizoru na sledování porna, jinak budete chránit lokální účet na PC za firewallem, jinak přístup do fóra na root.cz a jinak do banky.

Vždy je to o manažerském rozhodnutí: co chráním, jaká ztráta plyne z neoprávněného přístupu a jaká ztráta plyne ze zbytečně odepřeného přístupu. V takovém rozhodování není objektivní měřítko.

Dovolím si ale tvrdit, že kdo toto nechápe (a položí takový dotaz), by to neměl rozhodovat a měl by to přenechat na někom zkušenějším.

67

/dev/null / Re:COVID očkovací certifikát

« kdy: 21. 07. 2021, 17:24:33 »

Ono se stejně neočekává, že by někdo prováděl takovou úroveň ověření. Ten, kdo nemá certifikát v mobilu, stejně přijde jen s obyčejným papírem, který má stejnou platnost.

Digitální podpis by tam byl zcela zbytečně, překračoval by to, co se od toho dokumentu očekává.

Všechny potřebné informace jsou v QR kódu, a kdo chce, ověří si je (což se stejně v praxi neděje).

68

Odkladiště / Re:Čeština a IT výrazy

« kdy: 14. 07. 2021, 14:31:17 »

Já mám takový zajímavý poznatek, nebo spíš vlastní tezi.

Potkávám programátory, kteří nemají špatnou českou slovní zásobu. Přesto, když se baví o problému, i když se snaží, tak jim nenaskakují české výrazy.

Vysvětluju si to, že je to podobné, jako s učením jazyků. Někdo umí plynule přepínat mezi rodným a naučeným. Někdo se umí po chvíli plně adaptovat do druhého jazyka, ale neumí přepínat zpět do rodného. Někdo dokonce rodný jazyk začne zapomínat.

Podle mě tyto fenomény spolu souvisejí. Společná platforma pro komunikaci všech typů lidí je právě ten argot, který se vytvoří. Pomáhá těm, kteří "přepínat" neumějí, zatímco ostatní se dokáží přizpůsobit.

Mně osobně tahají počeštěné cizí výrazy za uši, zejména v popisném sdělení. Považuju to trochu za lenost.

69

Sítě / Re:Provoz přes VPN na Mikrotik

« kdy: 14. 07. 2021, 09:00:07 »

Já teda nechápu, proč jsou 2 IP rozsahy na chatě. Možná nákres by pomohl porozumění.

Ten druhý je rozsah směrem k providerovi. Pan kolega ho napsal, aby ukázal, že čísla sítí mezi sebou kolidují.

To jsem si myslel, ale přijde mi divný že by mu ISP dal masku /24 a tento rozsah.

Možná se zkusit domluvit s ISP ať Vám přeadresuje subnet pro WAN.

Tohle se dá řešit poměrně jednoduše dvěma způsoby.
Pokud má znalosti, tak přes VRF. Není to žádná atomová věda, ale už to vyžaduje znát síťování.

Rychlé vykoupení je ale v tom, vrazit před ten router ještě jeden malý, laciný, který do toho vrazí jinak očíslovanou síť. Routery, které potřebuje propojit VPN pak nebudou mít kolize IP adres.

Nedělal bych z toho zase takové drama .

70

Sítě / Re:Provoz přes VPN na Mikrotik

« kdy: 14. 07. 2021, 08:32:42 »

Já teda nechápu, proč jsou 2 IP rozsahy na chatě. Možná nákres by pomohl porozumění.

Ten druhý je rozsah směrem k providerovi. Pan kolega ho napsal, aby ukázal, že čísla sítí mezi sebou kolidují.

71

Sítě / Re:Provoz přes VPN na Mikrotik

« kdy: 13. 07. 2021, 23:57:18 »

Co to placas. Jasne tam ma napsano:

IP rozsah CHATA je 192.168.88.0-250 GE: 192.168.88.1

To ze ma za natem 192.168.1.0 je uplne jedno..

Není. Po propojení sítí bude mít v routovací tabulce 192.168/24 jak ethernetu, tak v tunelu.
Vzhledem k tomu, že na této síti bude hledat bránu, tak si ji připojením VPN buďto odřízne, nebo se nedostane do sítě přes VPN (podle toho, jak budou nastavené metriky).

72

Sítě / Re:Provoz přes VPN na Mikrotik

« kdy: 13. 07. 2021, 23:10:39 »

Určitě to řešit přes VRF, to by mělo být automaticky první řešení, jakmile se směrují víc jak dva nestejně postavené segmenty. VRF se hodně opomíjí a bastlí se to firewallem.

Nicméně, to už je nastavení, které není triviální popsat ani v docela dlouhém článku, natož jako odpověď v diskusi. Pokud pan kolega sítím tolik nerozumí (což se zdá), tak asi rychlé vykoupení je to přečíslování rozsahů, vyhnout se VRF a nabastlit to firewallem.

73

Vývoj / Re:Rada při návrhu db tabulek

« kdy: 07. 07. 2021, 10:38:18 »

Ale pracuje s tím i programátor,

Nepracuje. Proč by programátor měl vědět víc než ORM? Neví.
Zkus prosím toto zohlednit, a možná se posuneme dále.

Já myslím, že jsme u jádra pudla.
Zkusíme to na malých a extrémních příkladech.

Zkuste mi prosím popsat, jak by ORM mohlo vědět např. kdy se vyplatí z DB vytáhnout více dat hromadně dopředu, když v daný okamžik má požadavek třeba jen na jeden záznam - přičemž programátor s určitou přesností ví, že bude potřebovat vybranou sadu záznamů? ORM se může rozhodnout mezi dvěma extrémy - vzít a doručit jednu položku (a pokud to bude ve smyčcce, tak vygeneruje spoustu dotazů), nebo natáhnout do aplikace všechny (třeba i spoustu zbytečných). ORM není schopno rozhodnout "nic mezi", zatímco programátor s určitým úspěchem ano.

Nebo, někdy se vyplatí k záznamům rovnou dotáhnout (joinem) navázané informace. Aplikace je může potřebovat až někdy později za běhu, ale ví se, že je potřebovat bude (v některých případech). ORM se zase může leda rozhodnout, že je dotáhne ad hoc po jednom (spousta dotazů ve smyčce), ad hoc hromadně (pak join provádí aplikace svojí logikou), nebo dopředu (tj. bude je tahat i v případech, kdy nebudou potřeba). Opět, toto může ovlivnit jedině programátor tím, že to tomu ORM dá nějak na vědomí.

To jsou dva úplně triviální příklady, kdy se ORM nemůže rozhodnout za programátora. Ano, programátor může ORM nahintovat, aby se zachovalo tak, jak si představuje. Tím se ale ztrácí kus univerzálnosti ORM řešení, a navíc ten programátor stejně musí znát, co je v pozadí. Bez toho nemůže vědět, jak hintovat.

Já mluvil o milisekundách spálených na mapování výsledku dotazu na objektovou reprezentaci. V žádném případě na tom, že by ORM mělo posílat horší dotazy než by napsal vývojář.

Zbytek je opět sklouznutí ke steskům nad nekvalitou ORM.

Ta ztráta času je především v tom, že potřebujete snížit počet dotazů i za cenu komplikovaného dotazu. Potřebujete to snížit, abyste omezil obvykle neefektivní aplikační logiku a nekumuloval dotazové latence. Jak jsem psal výše, to rozhodnutí nejde udělat v rámci automatiky ORM.

74

Vývoj / Re:Rada při návrhu db tabulek

« kdy: 02. 07. 2021, 14:43:01 »

@BoneFlute

Podle mě v té Vaší úvaze zanedbáváte právě to, co je skutečnou překážkou.

ORM, na to, aby mohlo dělat práci blízkou optimu, musí databázi znát. Dobře, strukturu zná, protože si ji spravuje. Co nezná, jsou ty statistiky (nikoliv dotazů, ale tabulek - jejich dat a rozložení). ORM netuší, jestli v jedné tabuli je 100 záznamů a v druhé milion, nebo naopak. Neví, jestli jsou hodnoty rozprostřené rovnoměrně, nebo nerovnoměrně.

S touto znalostí pracuje databáze (vy říkáte, že to jí tím neseberete). Ale pracuje s tím i programátor, protože ten podle toho volí způsob dotazu (Pavel vypisoval šířeji). ORM zvolí outer join tam, kde programátor usoudí, že může zvolit inner join. ORM zvolí subselect tam, kde programátor zvolí (lateral) join. ORM zvolí posloupnost dotazů tam, kde programátor jeden složený. ORM uzamkne příliš, tam, kde programátor může usoudit, že stačí méně. To jsou ta nepřekročitelná omezení (resp. překročitelná jsou jedině tak, že se v ORM stejně uchýlí k sestavení konkrétního dotazu).

Ani s tou milisekundou sem, milisekundou tam podle mě nemáte pravdu. Obecně ORM systémy generují vyšší počet dotazů. Když máte 50 dotazů na úkon, a na každém dotazu ztratíte 5 ms a k systému přistupuje 100 lidí, vytvoříte si lap 25 sekund. V lepším případě se to projeví jen tím, že každý uživatel čeká o čtvrt sekundy déle, což bývá přijatelné. V horším případě čekají transakce za sebou (kvůli ACID) a lap na uživatel je mnohem vyšší.

Podle mě v úvahách směřujete spíš od ORM k nějaké objektové databázi, která aspoň některé z problémů řeší (ale zase přináší trochu jiné).

Ale jinak fajn diskuse, dává mi to trochu větší vhled do toho, jak o tom přemýšlejí ORM uživatelé, a jak bídně umím popsat to, co jsem přesvědčený, že je hlavní a nepřekročitelný problém. Díky.

75

Vývoj / Re:Rada při návrhu db tabulek

« kdy: 01. 07. 2021, 22:37:31 »

Já se opravdu nechci bavit o tom, že aktuální ORM implementace mají velké problémy. Já se zajímám o prinicipielní problémy.

Možná se nesrozumitelně vyjadřuju, beru. Pokusím se tedy shrnout:

Principiální problém je v tom, že ORM je vrstva nad databází. Očekává se od ní trochu něco jiného než od té databáze.

Pokud bychom přijali, že ideální ORM bude 100% efektivní abstrakce nad databází, v podstatě pak už by databáze nebyla potřeba. Do ORM by se doimplementovaly storage operace a bylo by hotovo.

ORM - jakožto pojem - má smysl jen právě proto, že nepřívětivé vlastnosti databáze mapuje do přívětivých objektových operací ve vyšším programovacím jazyce. Toto nelze vyřešit jinak, než kompromisem. Tedy ztráta pramenící z principu, nikoliv z implementace.

Pavel trefně zmínil absenci statistik (které samy o sobě nedávají 100% odraz skutečnosti). Taky to, že co má databáze při ruce s minimální režií, ORM může získat jen za cenu poměrně vysoké režie (síťová, a další mezivrstvy). Tedy další ztráta pramenící z principu a ne z implementace.

A pak je tu ten třetí důvod, o kterém můžeme diskutovat, jestli je principiální, nebo implementační. To je volba strategie programátorem. Já ji považuji za principiální. U složitých úloh by se jistě dalo uvažovat o tom, že budoucí optimalizátory budou rychlejší a efektivnější. Jenže pořád tu zůstává velká řada triviálních úloh, u kterých může programátor strategii přímo určit a lze ji považovat za optimální. Tedy, můžeme diskutovat o tom, že by v budoucnu mohlo ORM (kdyby mělo statistiky a mohlo vytvářet hinty), mohlo být efektivnější ve složitých úlohách, než ploché SQL, protože ORM má o struktuře dat trochu jiné, a v určitém ohledu lepší informace. Stejný mechanismus by však zdržoval u triviálních úloh, u kterých by programátor stejně dál preferoval sám určit a vysvětlit postup vykonání. Tedy, ručnímu zásahu by se nedalo vyhnout, pokud bychom hledali výkon.