Příspěvky

1

Sítě / Re:Vytvoření anonymní identity na internetu

« kdy: 05. 05. 2026, 14:36:26 »

Můžeš to sice prohnat přes x "proxy" počítačů y krát kolem celé zeměkolule, ale těm proxy počítačům musíš opatřit internetové připojení. Budeš muset někde něco nějak zaplatit. Takže musíš najít takový způsob platby, kterým tě nemohou vystopovat. A obávám se, že ani ten Bitcoin není úplně beze stopy. Patrně se budeš muset nakonec smířit s určitou mírou pravděpodobnosti vystopování a s tou budeš muset žít.

2

Hardware / Re:Jaký FS použít pro dlouhodobou archivaci?

« kdy: 19. 04. 2026, 17:51:59 »

Pokud to těch 20 let vydrží ten disk, tak je to snad celkem jedno, ne? Ale ono to s tou výdrží může být celkem dost velký problém. Buď se disk bude celou dobu točit a pak velmi pravděpodobně fyzicky nevydrží. Nebo bude v šuplíku a za 20 let se vůbec neroztočí. A nebo, a to nejpravděpodoněji, ho za 20 let nebude k čemu připojit, protože se změní standardy.

Ale ten souborový systém by měl mít také nějakou interní kontrolu toho, že data na něm jsou korektní. A bylo by dost otravné za 20 let zjistit, že máš sice funkční disk i funkční souborový systém, ale bohužel diskem proletěly nějaké částice, které změnily data zrovna tam, kde tě zajímají, bylo by docela vhodné, mít tam něco, co takové chyby dokáže také odstranit. Protože jinak taková funkce bude muset být přímo v těch uložených datech. Něco jako když RAR ukládá data navíc k tomuto účelu.

A nechápu co se ti nazdá na ZFS a BTRFS. Filesystémy jsou rozšířené oba dost a právě některé z výše uvedených problémů řeší.

3

Distribuce / Re:Neaktualizované balíky v Debianu testing

« kdy: 05. 04. 2026, 09:35:10 »

Já na firefox kašlu, používám esr verzi ze stable. Kodi mám na samostatném hardwaru a to se upgraduje samo, pokud má z čeho.

Kromě toho se mrkni sem: https://packages.debian.org/search?keywords=kodi&searchon=names&suite=all&section=all a uvidíš, že kodi v testingu vůbec není, zato ale je v unstable. A tohle je zrovna typický příklad toho, že se některé balíky do testingu ani nemusejí dostat, protože dřív, než z unstable propadnou do testingu, objeví se v unstable nová verze a ta předchozí, čekající na zařazení do testingu, zmizí.

A i tak může stát, že tu novou verzi z testingu/unstable nenainstaluješ, protože je přeložena s jinými závislostmi, které nedokážeš splnit buď z výše uvedeného důvodu a nebo proto, když se to třeba pokoušíš instalovat do stable, že by to vyžadovalo přeinstalaci skoro celého systému - aby se vyřešily ty závislosti. Takže nakonec skončíš s tím, že tam máš z větší části unstable, a i to se občas rozbije.

4

Distribuce / Re:Neaktualizované balíky v Debianu testing

« kdy: 04. 04. 2026, 22:38:07 »

Nedávno jsem aktualizoval na další debian testing a od té doby mi při aktualizacích visí nějaké balíčky.

To je celkem normální stav, pokud používáš testing. Občas se to prostě rozbije. To vyplývá z toho, jakým způsobem se balíky dostávají do testingu. Pokud to nechceš nebo neumíš řešit, používej stable. Pokud mermomocí trváš na nových balících, musíš občas použít také unstable nebo dokonce experimental - a pomocí preferencí ovlivnit, co se má nebo nemá z jaké release instalovat. Někdy to jde, někdy to ale také nejde.

5

Studium a uplatnění / Re:Ohodnocení scrum master vs. developer/tester

« kdy: 03. 02. 2026, 10:02:59 »

naberam dojem, ze ich cinnost je zucastnovat sa na mitingoch a niekedy prudit ludi, ktori robia nieco realne.

A není to je v podstatě správná definice té pozice?
I když, možná by to šlo ještě lépe. Je tam málo cizích slov...

6

Server / Re:Pošta z Gmail.com má zpoždění několik hodin

« kdy: 21. 12. 2025, 22:22:40 »

ten greylisting je jednak o dost méně náročný i než ověřovat SPF a DKIM

O tom se dá s úspěchem pochybovat.

Tadyhle milter-greylist může provádět rovnou spf check a když je zájem, dá se nastavit tak, že spojení, která mají správně spf, nejsou greylistována.

https://manpages.debian.org/testing/milter-greylist/greylist.conf.5.en.html

7

Server / Re:Pošta z Gmail.com má zpoždění několik hodin

« kdy: 19. 12. 2025, 18:29:03 »

p=none je jen pro identifikaci, co vám odkud chodí, ale neposkytuje žádnou ochranu
Jakékoliv hodnocení SMTP serveru s DMARC p=none vám řekne, že to není dobře.
Popsáno třeba zde: https://powerdmarc.com/what-is-dmarc-policy/

Já vím, k čemu to slouží. Ale nikde jsem se nedočetl, že by Googlu nestačilo, když tam je "none".

8

Server / Re:Pošta z Gmail.com má zpoždění několik hodin

« kdy: 19. 12. 2025, 17:36:50 »

Politiku none mít v DMARC nemůžete, protože to vám nedovolí velcí hráči.

Tohle s píše kde? Nic takového jsem se nedočetl u Googlu ani Microsoftu. Tak kdo to nemá rád?

9

Server / Re:Pošta z Gmail.com má zpoždění několik hodin

« kdy: 18. 12. 2025, 23:52:14 »

Když se někdo pokusí poslat spam, tak se dostane na blacklist. A to daleko dřív, než toho spamu bude miliarda.

Ta lepší varianta je, že nesledujete kontext diskuse a tak nevíte, že se tu bavíme o greylistingu. Horší varianta by byla, kdybyste si myslel, že se někdo na základě greylistu dostane na blacklist.

OK. Když mi na server s greylistingem pošlete miliardu spamu z miliardy kombinací ip adresa, odesílatel, příjemce, tak mi server odstřelíte. Ale server žádný spam nepřijme. Ale takový způsob odstřelení mého serveru bude pro vás, podle mého názoru, neefektivní. Mnohem jednodušší by bylo, odstřelit ho množstvím otevřených spojení, ideálně z vašeho botnetu...

Pokud bude vaším cílem opravdu doručit nějaký spam, tak musíte mít napřed správně nastavený odesílající server. Pak budete muset zkousnout ten greylisting a na závěr se vám stejně může stát, že přijdete na ten blacklist a server se s vámi přestane bavit.

10

Server / Re:Pošta z Gmail.com má zpoždění několik hodin

« kdy: 18. 12. 2025, 17:38:31 »

Takže když vám někdo pošle miliardu spamu

Když se někdo pokusí poslat spam, tak se dostane na blacklist. A to daleko dřív, než toho spamu bude miliarda.

11

Server / Re:Blokace domén začínajících danými znaky

« kdy: 13. 11. 2025, 14:51:51 »

A v 6.x se dá to samé použít taky, i když to není ideální.

V 6 jsem to zkoušel, ale nezadařilo se mi tam naroubovat ten script.

12

Server / Re:Blokace domén začínajících danými znaky

« kdy: 13. 11. 2025, 11:42:41 »

AI tvrdí, že to umí knot-resolver pomocí lua scriptů. Ale jen stabilní verze 5, ne verze 6. Nezkoušel jsem.

13

Server / Re:Blokace domén začínajících danými znaky

« kdy: 12. 11. 2025, 07:54:32 »

Pardon, přehlédl jsem, že jsem nenapsal, že chci blokovat na síťovém DNS pro ostatní zařízení v LAN.

Takže zařízení z vnitřní sítě lezou ven na ty domény, ale tobě se to nelíbí a chceš je na úrovni DNS bloknout?

A nemůže se stát, že po úspěšném zavedení DNS blokace, si provinilci nastaví DNS over HTTPS?

14

Software / Re:Nekorektní chování BTRFS

« kdy: 03. 11. 2025, 23:42:31 »

ano

Ne.

Btrfs je CoW, takže když má fungovat, potřebuje nějaké volné místo. Je to něco podobného, jako SSD. Btrfs se sice dá zaplnit skoro na 100%, jak máme zde uvedený příklad, ale potom se od toho nedá očekávat žádný výkon. Ta data by na tom musela pouze ležet. Ale pokud se mají točit, musí tam být přiměřený volný prostor.

15

Odkladiště / Re:OSVČ a komunikace s OSPOD

« kdy: 03. 11. 2025, 15:35:24 »

obě datové schrány jsou datové schránky té jedné a samé fyzické osoby

No však jo. To jiní se tady tvářili, jakoby DSFO a DSPFO patřily každá někomu jinému.

Tohle je zavádějící. Pokud to chcete brát takhle, tak ale musíte dodat, že DS FO slouží pro úkony fyzické osoby, které nesouvisí s podnikáním, a DS PFO souvisí pro úkony související s podnikáním.

Jednodušší, než to takhle opisovat, je napsat, že DS FO patří občanovi, DS PFO patří OSVČ (podnikající osobě).

Já přece vím, k čemu ty datové schránky teoreticky slouží. A doufám, že i vy uznáte, že ty schránky, o kterých se bavíme, patří jedné konkrétní fyzické entitě - nějakému člověku.

Mně tedy ale šlo především o to, že všechny ty různé DS pro jednoho člověka se ani prakticky nepoužívají. Ale opečovávat se přesto musejí.