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 ... 33 34 [35] 36 37 ... 375
511
Sítě / Re:Routování mezi dvěma IP rozsahy
« kdy: 23. 08. 2022, 10:35:24 »
Ty doby, kdy jsem se radoval, že Unix se dá konfigurovat čistě přes texťáky, jsou bohužel pryč.
Ale nejsou. Linuxové distribuce se stále konfigurují přes textové soubory, akorát musíte vědět, co se kde konfiguruje.

512
Sítě / Re:Routování mezi dvěma IP rozsahy
« kdy: 23. 08. 2022, 10:34:17 »
Kód: [Vybrat]
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet dhcp

auto eth1
iface eth1 inet static
     address 192.168.200.1
     netmask 255.255.255.0

Vše ostatní jsem smazal. Je to tak správně?

Na první pohled tam žádnou chybu nevidím. Pokud vám to bude fungovat, považoval bych to za správné :-)

513
Sítě / Re:Routování mezi dvěma IP rozsahy
« kdy: 22. 08. 2022, 22:22:33 »
Zrušte ten bridge, nedává tam žádný smysl. Pak už stačí jenom eth1 nastavit statickou IP adresu ze stejné sítě, jako má zařízení 1. Tu nenastavujte příkazem, ale v konfiguraci - tím se zajistí to, že ot bude fungovat i po restartu. Nastavte ji v /etc/network/interfaces, volba address.

514
Sítě / Re:Routování mezi dvěma IP rozsahy
« kdy: 22. 08. 2022, 18:06:16 »
Začněte tím, že to popíšete tak, aby se v tom dalo vyznat. Píšete o „zařízení“, „minipc“, „druhé zařízení“ – druhé zařízení je  to první zařízení s pevnou IP adresou, nebo je to třetí zařízení v síti? eth0 a eth1 jsou na tom minipc? Pokud ano, tak konfigurace, kdy máte dvě zařízení v bridge, a přitom je každé v jiné IP síti, je dost zvláštní. Bridge propojuje dvě fyzické sítě do jedné, takže pak nad tou jednou fyzickou sítí máte jednu IP síť.

Každopádně na konfiguraci v linuxu nepoužívejte ifconfig, který je v linuxu zastaralý už přes 20 let a nefunguje správně.

515
Prostě dokud se do du nezamíchají vnořené složky je to OK, ale složky tam nesprávně přispívají různými velikostmi.
Nikoli, složky tam správně přispívají svými velikostmi. Protože i to, že složka obsahuje soubory a další složky, musí být někde uloženo. A je to uloženo přesně na tom samém místě, kde má soubor uložena data souboru. Takže složky na linuxu opravdu mají svou velikost a du ji započítává.

516
Desktop / Re:Read only root
« kdy: 16. 08. 2022, 12:02:48 »
Fedora Silverblue. Jiří Eischmann tu o ní před pár lety psal článek: (Téměř) rok na Silverblue: Fedora s úplně hladkými aktualizacemi.

517
Software / Re:Archivace každé složky samostatné (7zip)
« kdy: 15. 08. 2022, 14:56:36 »
%~dp0 na Windows údajně znamená disk a cesta k aktuálně spuštěnému programu. V linuxu je cesta k aktuálně spuštěnému programu uložená v proměnné prostředí $0 (včetně názvu souboru). Takže cestu k adresáři, kde je skript uložen, si můžete uložit do proměnné ROOT_DIR třeba takhle:
Citace
#!/bin/bash
ROOT_DIR=`dirname $0`

Pak už stačí ten adresář jenom pomocí find projít.

518
Server / Re:Nginx před Apachem kvůli HTTP/2
« kdy: 08. 08. 2022, 14:03:42 »
Zrychlení odezvy ovlivní akorát to, pokud budete mít HTTP/2 mezi prohlížečem a prvním serverem – ve vašem případě tedy aktuálně reverzní proxy nginx. Pokud potřebujete řešit rychlost odezvy, doporučuju nechat tam ten nginx jako reverzní proxy, na tom se vám to bude ladit nejlépe. Můžete tam používat moderní protokoly, dobře řešit cachování, servírovat statické soubory apod.

519
Vývoj / Re:Vývoj mobilní aplikace pro osobní použití
« kdy: 08. 08. 2022, 13:01:02 »
Mnohem jednodušší, než to programovat od začátku (zvlášť když nejste programátor), je použít na to nějakou už hotovou aplikaci. Aplikací na evidenci práce jsou tisíce.

Jinak na tohle by stačila i jednoduchá webová aplikace. Dala by se udělat jako PWA, tzn. pak by šla na Androidu nainstalovat její ikona a aplikace by mohla fungovat i v offline režimu. Před pár měsíci o tom vyšel článek na Zdrojáku: Offline stránka v PWA přes ServiceWorker.

520
Vývoj / Re:TIME_WAIT po ukončení socket-komunikace
« kdy: 08. 08. 2022, 12:56:57 »
Takhle je to správně. Ta lhůta je tam proto, že i po ukončení spojení mohou dorazit pakety, které patří do toho spojení. Je lepší je umět zařadit, kam patřily, než je brát jako neznámé pakety (nebo v horším případě je zařadit do jiného spojení, kam by podle portů mohly spadnout).

521
Server / Re:Nginx před Apachem kvůli HTTP/2
« kdy: 08. 08. 2022, 11:51:09 »
Vzhledem k tomu, že HTTP PUSH přestaly prohlížeče podporovat, není podle mne důvod používat HTTP/2 mezi reverzní proxy a backendem. Získalo by se tím jenom multiplexování spojení, ale to není mezi reverzní proxy a backendem potřeba (prostě se tam naváže tolik spojení, kolik je potřeba).

Takže je otázka, proč vlastně na tom Apache chce petr0707 zapínat HTTP/2.

522
Server / Re:Nginx před Apachem kvůli HTTP/2
« kdy: 08. 08. 2022, 09:27:58 »
Apache zvládne prakticky všechno, co nginx, a ještě daleko víc. nginx se používá proto, že je „lehčí“, takže se stejnými zdroji zvládne odbavit větší provoz, než Apache. Pro HTTP/2 nepotřebujete HTTPS – prohlížeče implementují HTTP/2 jen nad HTTPS, ale servery implementují i nešifrované HTTP/2 (označuje se h2c).

523
Server / Re:SQL dotaz: defragmentace tabulky
« kdy: 07. 08. 2022, 10:14:01 »
Vzhledem k tomu, co a jak tady píšete, byste to měl nechat na někom zkušenějším. Například aby zjistil , v čem je vůbec problém, a zda je nějaká defragmentace vlastně potřeba.

Jinak defragmentace se z principu nedá udělat pro „nejmladší záznamy“. Defragmentace vzniká tak, že se mažou záznamy, a zůstává po nich volné místo, případně se na jejich místo zapíší novější záznamy. Mohl byste vzít nové záznamy z celé tabulky a posbírat je na jedno místo na konec, přístup k novějším záznamům sekvenčním čtením byste zlepšil, ale tam, odkud jste ty záznamy vzal, by zase vzniklo prázdné místo – takže byste tu tabulku zároveň i ještě víc fragmentoval. Takovému procesu by se těžko mohlo říkat „defragmentace“.

Defragmentace tabulky neznamená, že by se záznamy mazaly. Při defragmentaci se záznamy jen přesouvají. Pořád nevíme, co je to za databázi, každopádně přístupy k defragmentaci jsou možné v zásadě dva. Jeden, jednodušší na implementaci, je prostě všechny záznamy zapsat znovu správně seřazené do nové tabulky. Při takovém přístupu je ovšem potřeba až dvojnásobný prostor proti původní tabulce – v jednu chvíli budete mít na disku celou tabulku dvakrát. Druhá možnost je dělat to na místě, tj. opravdu prohazovat jednotlivé záznamy. Takhle se defragmentují disky, protože k tomu není potřeba další prostor.

524
Hardware / Re:proxmark3 - klonování čipů(domovní dveře)
« kdy: 20. 07. 2022, 19:47:05 »
Spousta těchhle systémů se řídí jenom identifikátorem RFID čipu, takže ta žádné šifrování není. Musel byste znát konkrétní typ systému, aby se dalo určit, co se tam používá.

525
Odkladiště / Re:Pořízení anonymní domény
« kdy: 13. 07. 2022, 19:28:41 »
Na ty websockety jsem se už vykašlal, ty JSONy jsou mnohem lepší :) Jinak ale stahování dat z internetu, pokud ten samotnej obsah není nelegální (dětské porno atd) popř. z nějakýho důvodu chráněnej (např. emaily), je to pro osobní potřebu, nedochází při tom k prolomení nějakýho zabezpečení (hacking atd) a nezpůsobuje se tím někomu škoda/újma, tak je naprosto legální a to i ve velkém množství :)
Ono je to trochu komplikovanější. Nejenom, že ten obsah nesmí být nelegální, ale ani nesmí být zveřejněn nelegálně. A pak je tam samozřejmě to omezení pro osobní potřebu – to znamená, že ta stažená data nesmíte šířit dál, ale ani nesmíte šířit nic, co byste zpracováním těch dat získal. Takže třeba nějaké statistiky si pro osobní potřebu dělat můžete, ale už je nemůžete poskytovat nikomu jinému. Nebo-li zrovna vlastní doména vám v tomhle případě bude úplně k ničemu. Ale pokud ta doména vůbec nijak nesouvisí s tím stahováním autorských děl, je to samozřejmě něco jiného.

Stran: 1 ... 33 34 [35] 36 37 ... 375