reklama

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 [2] 3 4 ... 240
16
Server / Re:Cloud disk (FTP, SFTP)
« kdy: 13. 02. 2020, 23:02:52 »
Dobrý den v protokolu mám zcela jasno, potřebuji SFTP protokol nebo NFS (pro jednoduchost přiložené foto).
Dobře, v původním dotazu bylo něco jiného.

Jak jsem psal, OVH NAS umí NFS. Jinak bych zkusil googlit SFTP cloud. Asi toho bude míň, než řešení přes HTTPS, on je přeci jen SFTP protokol pro cloud nevhodný, ale Google něco najde.

17
Odkladiště / Re:scan všech veřejných domén
« kdy: 12. 02. 2020, 21:00:34 »
Podle toho, co píšete, nechcete skenovat všechny dostupné domény, ale weby. 0.0.0.0 až 255.255.255.255 nejsou domény, ale IP adresy. Na jedné IP adrese může běžet web server, který hostuje stovky různých domén. Když jejich názvy neznáte, server vám je nemusí prozradit. CZ.NIC veřejný seznam domén neposkytuje. Ve výjimečných případech poskytuje seznam domén pro nějaké studijní nebo výzkumné účely, což váš projekt nesplňuje. Navíc seznam domén by vám opět byl k ničemu – z toho, že existuje root.cz, se nedozvíte, že existuje také forum.root.cz.

To, co jste popsal jako c), je přesně ta cesta, kterou používá Google i všichni ostatní. Prostě začnete nějakým seznamem stránek a následujete odkazy. Samozřejmě tak neobjevíte vše, ale ani Google nemá zaindexované ani zdaleka vše. Akorát nezačínejte nejnavštěvovanějšími stránkami (k těm bude patřit třeba domovská stránka Googlu, a tam moc odkazů neobjevíte), spíš začněte stránkami, které mají hodně externích odkazů – katalogy, Wikipedie, agregátory, média.

18
Server / Re:Fyzické uložení dat u relačních databází
« kdy: 07. 02. 2020, 08:45:44 »
Nejmenovana databaze mela maintenance prikaz vacuum urceny prave k uklizeni bordelu po vami popsanych praktikach ,)
PostgreSQL neukládá záznamy způsobem, který jsme popsal. Neoptimální stav databáze vzniká i jinými způsoby. Např. i když ukládáte data s pevnou délkou záznamu, pokud smažete víc záznamů než přidáte, pořád vám vznikne v souboru díra. Navíc PostgreSQL je MVCC databáze, která i updatovaný řádek zapisuje na nové místo, aby původní řádek byl k dispozici ostatním transakcím a pro případný rollback. Fyzické uložení dat v PostgreSQL je popsané zde: Database Physical Storage.

19
Server / Re:Fyzické uložení dat u relačních databází
« kdy: 06. 02. 2020, 23:28:59 »
Začnu od konce – vyhledávání pomocí indexu funguje rychleji díky tomu, že je index uspořádán tak, aby v něm bylo možné rychle hledat. Třeba v rejstříku v knize také najdete potřebné slovo rychleji než v knize samotné – protože je řazen abecedně, což vám hledání usnadní. Jestli je index v paměti nebo na disku s tím nesouvisí. Samozřejmě že hledání v indexu v paměti je rychlejší, ale je běžné, že databáze má tolik indexů nebo jsou tak velké, že se do paměti nevejdou.

Dohledávání dat přímo v tabulce nejde nijak zvlášť rychle a data nejsou ukládána nijak speciálně, aby je bylo možné rychle dohledat. Pro rychlé hledání slouží právě indexy. Data na disku by klidně mohla být uložena jednoduše jeden záznam za druhým (s proměnlivou délkou řádku), v indexu byste pak měl odkaz na místo (od začátku souboru), kde jsou data zapsaná. To, že se data ve skutečnosti obvykle zapisují jiným způsobem, je spíš optimalizace kvůli velikosti souboru. Kdyby se data zapisovala výše uvedeným způsobem, při změně záznamu by se větší záznam musel zapsat na konec souboru a po původním záznamu by zbyla díra, menší záznam by se mohl zapsat na původní místo, ale zbyla by tam díra o velikosti rozdílu starého a nového záznamu. Nebo.li by docházelo k fragmentaci souboru – vedle užitečných dat byste tam měl spoustu nevyužitých prázdných míst, která by jen nafukovala velikost souboru.

20
Server / Re:Cloud disk (FTP, SFTP)
« kdy: 06. 02. 2020, 23:20:20 »
Cloud Diskem myslíte normální síťové úložiště souborů poskytované jako služba? Axfone disk umí FTP, WEDOS Disk umí FTP, OVH Backup Storage umí FTP a FTPS, OVH NAS umí NFS. Jak jsou na tom další poskytovatelé nevím, díval jsem se jen na tyto tři.

Mimochodem, SFTP je úplně něco jiného, než FTP – SFTP je přenos souborů nad SSH spojením. Takže jako první si udělejte jasno v tom, které protokoly jsou Acronisem podporované.

21
Windows a jiné systémy / Re:Windows 10 jako webový server
« kdy: 05. 02. 2020, 18:56:21 »
Pokud to budou používat 3 uživatelé, každý ze svého pracovního PC, notebooku, domácího PC, mobilu a tabletu, pořád ještě 5 licencí zbyde…

22
Software / Re:Elektronický podpis; přenos důvěry
« kdy: 04. 02. 2020, 23:41:20 »
Připojení k internetu nepotřebujete.

Podpis obsahuje hash dokumentu podepsaný privátním klíčem podepisující osoby a certifikát podepisující osoby – veřejný klíč v certifikátu musí odpovídat privátnímu klíči použitému pro podpis.

Podpis se ověřuje tak, že pomocí veřejného klíče „dešifrujete“ podpis, vyjde vám hash a ten porovnáte s hashem dokumentu, který si sám spočítáte. Následně se stejným způsobem ověří podpis certifikační autority na certifikátu. Certifikát certifikační autority (spolu s jejím veřejným klíčem) máte v úložišti certifikátů, kterým důvěřujete. Někdy může být s podpisem poslán i certifikát certifikační autority, často totiž není řetězec jen dvoudílný (certifikační autorita a koncový certifikát osoby), ale těch certifikátů certifikačních autorit je v řetězci víc (např. autorita vydávající certifikáty pro kvalifikovaný podpis a její certifikát je podepsán kořenovou autoritou). Každopádně při ověřování podpisu musíte vždy dojít k certifikátu nějaké autority, které důvěřujete a který máte tím pádem nainstalovaný v systému. Pokud k takovému certifikátu nedojdete, musel byste si zjistit, o jakou autoritu se jedná, zjistit, jestli jí můžete důvěřovat, a pak bezpečným způsobem získat nebo ověřit její klíč. Což vůbec není snadné – pokud byste si certifikát stáhl přes internet, měl byste otisk klíče zkontrolovat minimálně jedním nezávislým kanálem, třeba telefonicky. V praxi se to proto moc nedělá a spoléhá se na ty certifikáty certifikačních autorit, které máte předinstalované v systému nebo v aplikaci.

23
Windows a jiné systémy / Re:Windows 10 jako WebServer?
« kdy: 04. 02. 2020, 20:22:35 »
Z pohledu funkčnosti je to tedy jedno, ta licence je otázka, dle mého to není legální.
I na ty malé servery na doma se dávala nějaká ta Small business verze. Možná někdo jiný tuší jak to je?
Pokud se na tuhle situaci opravdu vztahuje to, co citoval k3dAR (nehledal jsem, kde přesně to je v licenci uvedeno), pak by to legální mělo být – nedávalo by smysl, aby Microsoft na jednom místě explicitně jmenoval IIS, že se na něj vztahuje limit 20 připojených zařízení, a někde jinde napsal, že se tam IIS vlastně vůbec provozovat nesmí. Ale mohla by být jinde samozřejmě jiná omezení, např. že se tam nesmí provozovat produkční aplikace.

Pronajmout si virtuál není možné, protože data nemají opustit firmu. 
Já bych se tedy nejdřív zaměřil na tohle. To prostředí, které popisujete, vypadá, že je to řešené dost na koleně. Nic proti tomu, pro spoustu případů je to optimální. Ale bezpečnost takového řešení je podle mne o dost nižší, než když si pronajmete nějaký průměrný VPS, a ještě o další řád nižší, než kdybyste odebíral MySQL a IIS jako službu a jenom si na to nainstaloval svou aplikaci.

24
Vývoj / Re:LXD nebo Docker
« kdy: 04. 02. 2020, 17:43:01 »
... Podman je Docker udělaný správně (nebo alespoň podstatně lépe).

Mohl bys to rozvést?
Evidentně nejsem sám, kdo si to myslí – pokud vás to zajímá, na konci února bude v Praze meetup na téma
Podman - Docker done right
.

25
Vývoj / Re:PostgreSQL a primární klíč s funkcí?
« kdy: 30. 01. 2020, 23:45:03 »
Nečetl jsem vlákno celé, ale žiju v přesvědčení, že Postgres má Funkční indexy?
Ano, PostgreSQL má funkční indexy. Ale omezení na unikátnost (unique constraint) lze definovat pouze pro sloupce, ne pro výrazy. A primární klíč je jen speciální varianta omezení na unikátnost. Tj. ten index jde definovat, i jako unikátní index, ale nemůžete ho použít pro omezení.

26
Vývoj / Re:PostgreSQL a primární klíč s funkcí?
« kdy: 30. 01. 2020, 23:01:00 »
Aha, teď konečně ten dotaz dává smysl.

pokud máš nenulový počet uživatelů, co mají nutkavou potřebu do tabulek lézt nějakým tim table view čumítkem a tyto klikátka chtějí zkrátka primární klíč na tabulce. Bez něj buď odmítnou zobrazit nebo se podivně pošahají, když v tabulce je 500M+ řádků. To je jediný důvod, proč byla snaha přidat primární klíč.
Chápu, takže vy tyhle uživatele chcete potrestat. Uznávám, dát jim jako primární klíč složený klíč, jehož polovina bude půlka jiného sloupečku, a ještě to bude datum a čas, to je velmi rafinované. Ještě bych něco udělal s tou první půlku, integer je moc fádní – co takhle nějaký geospatial typ?

Nevýhoda tohohle trestu je to, že trestáte i sám sebe. Pokud se trestat nechcete, o typech SERIAL/BIGSERIAL sám píšete.

Nu, stejná skupina má občas snahu psát dotazy, kde do where nacpou něco jako "lower(casr) between T1 and T2", tak jsem chtěl zabít dvě mouchy jedním klíčem, že by jim to trochu zrychlilo, když nejsou schopni pochopit range operaci typu casr && (T1, T2]. :-)
Pokud by v tom dotazu nebyla i podmínka na smid, ten index by se neuplatnil.

Samozřejmě to jde řešit, že místo casr:tstzrange použít na to 3 samostatné sloupce (casl:timestamp, casu:timestamp, casb:char(2)) a vyrobit si nad tím primary index pomocí (smid, casl, casb) a kontrola nepřekrývání pomocí "exclude using gist (smid with =, tstzrange(casl, casu, casb) with &&)" funguje, akorát pak některé operace to nechtělo brát dle toho indexu na pozadí. Dotaz typu "select * from tab where tstzrange(casl, casu, casb) && '[ T1, T2]'" nechtěl použít index toho exclude, což při použití normálního range sloupce fungovalo. A historicky je to děláno vše na range, tak jsem nechtěl do toho tak hluboce rejpat.
V aktuálních verzích PostgreSQL by to mělo jít řešit generovanými sloupci. Obávám se, že kombinace stará databáze + uživatelé, kteří neumí psát SQL dotazy + velký objem dat je smrtelná a pokud jednu z těch věcí nevyřešíte, volil bych umělý primární klíč i za cenu toho, že tím na disku vznikne nový velký index. Tu verzi databáze ani uživatele jste si asi nevybral, tak si nekomplikujte život indexem, který stejně nikdo neocení u bude dělat problémy vám i těm uživatelům s čumítky.

27
Software / Re:Chromium dává kouř paměťové kartě
« kdy: 30. 01. 2020, 16:18:49 »
Řešil jsem to samé v chrome a vytěžuje to extrémně disk i jen při přehrávání videa. Přitom paměti je dost. To je jasný bug nebo úmysl (kontrola dat?).
Je to úmysl – dobré fungování prohlížeče, plynulé vykreslování a používání. Nejlepší využití paměti není takové, kdy ji zaplníte až po okraj. Navíc o využití paměti nerozhoduje aplikace, ale operační systém – takže prohlížeč musí počítat i s tím, že musí nějak „vyjít“ i s operačním systémem.

28
Software / Re:Chromium dává kouř paměťové kartě
« kdy: 30. 01. 2020, 12:32:57 »
Obvykle je síťová komunikace pořád to nejpomalejší médium, takže prohlížeč se snaží maximum věcí kešovat – netahat je po síti, ale mít je blíž, na disku, v RAM. Určitě jste radši, když vám zobrazí soubor z lokálního disku, než když ho musí tahat ze sítě. O to víc budete radši, pokud máte připojení účtované podle přenesených dat. No a udržovat cache tak, aby byla co nejefektivnější, je samozřejmě docela náročné. Nejlepší je samozřejmě mít vykreslenou stránku v RAM, jenže RAM není nekonečná, takže někdy se vyplatí mít v RAM jenom zdrojové soubory a teprve z nich v případě potřeby vykreslovat. Jenže i tak dokážete RAM rychle zaplnit, ale pořád je lepší mít ty soubory na disku než je nemít vůbec. Takže prohlížeč musí na základě toho, co děláte, s tou keší neustále pracovat – nahrávat do RAM to, co asi budete potřebovat, odkládat na disk to, co teď potřeba nebude, mazat z disku soubory, které jsou staré nebo jste je dlouho nepotřeboval.

Mít cache prohlížeče na paměťové kartě rozhodně není dobrý nápad, na desktopu se to dá srovnávat asi jenom se swapem (ono je to vlastně i funkčně hodně podobné).

29
Vývoj / Re:LXD nebo Docker
« kdy: 28. 01. 2020, 08:20:57 »
Nicméně zatím tu pořád vidím jen školení docker...., žádný henten podman...
(jen konstantuji)
V tom asi bude nějakou dobu trochu zmatek, protože dnes Docker znamená jak obecnou technologii, tak její konkrétní implementaci – a druhá implementace je Podman. Předpokládám, že ta školení jsou tak nazvaná mimo jiné proto, že Docker jako název té technologie je známý, Podman daleko méně. Nejspíš většina věcí, kterou se na tom školení naučíte (možná i všechny) budete moci využít i s Podmanem. Klidně je i možné, že se to ve skutečnosti bude školit na Podmanu.

30
Vývoj / Re:LXD nebo Docker
« kdy: 27. 01. 2020, 08:12:37 »
Abych pravdu řekl, moc nechápu ty rady použít LXD. V Dockeru/Podmanu si budu spouštět jednotlivé aplikace v samostatných kontejnerech, když se rozhodnu vyzkoušet Node.js 13 místo 12 LTS, prostě spustím další kontejner, když budu chtít mít tři různé konfigurace Pythonu, prostě budu mít tři různé kontejnery. Když budu chtít spustit testy na CI, vezmu hotový image s aplikací používaný pro vývoj a spustím ho na CI serveru.

Samozřejmě ten Docker kontejner nebude jeden, ale bude jich více – pro každou aplikaci jeden, pro používané služby (třeba NoSQL databáze) další (opět pro každou jeden).

LXD mi vytvoří nový plnohodnotný systém, takže místo svého počítače bych si dělal nepořádek v tom LXD. Tím ale přece nic nezískám. Stejně budu muset řešit ten nepořádek, stejně při přenosu aplikace jinam budu mít problém v tom, že mám v tom LXD své specifické prostředí.

Stran: 1 [2] 3 4 ... 240

reklama