Poslední příspěvky

Stran: [1] 2 3 ... 10
1
Odkladiště / Re:OSVČ a komunikace s OSPOD
« Poslední příspěvek od Filip Jirsák (forum) kdy Dnes v 09:33:19 »
A presne tohle neni pravda. Urad te nemuze jako fyzickou osobu ovcana kontaktovat pres DS podnikatele, ale naopak to akceptovat je povinen.
Ne, v opačném případě (podání úřadu z chybné DS) k tomu úřad musí přistupovat jako k podání s vadou a ověřit, kdo to doopravdy podal. Někdy to může udělat sám, někdy musí toho, kdo měl podání podat, vyzvat, aby podání potvrdil.

Pokud je osvc zaroven platcem DPH tak je jeho RC zaroven DIC
Není, DIČ je „CZ“ plus rodné číslo.

coz je mimochodem uz drahne let ilegalni
Nesmysl, není to ilegální.

protoze prohlasit, ze se dicem stava cz+ic (stejne jako u vsech firem) ... je nad schopnosti byrokratu.
Vůbec nejde o schopnosti byrokratů, ale o to, jak tu změnu technicky provést. DIČ se používá na spoustě míst a tím, že prohlásíte, že DIČ je něco jiného, se to všude zázrakem samo nepřepíše. Navíc DIČ je platné mezinárodně – nevím, zda se v mezinárodním styku vůbec počítá s tím, že se DIČ může změnit.

Změnit se mohlo alespoň to, aby nová DIČ PFO byla přidělována jinak.
2
Odkladiště / Re:OSVČ a komunikace s OSPOD
« Poslední příspěvek od jjrsk kdy Dnes v 09:04:32 »
Úkony konat můžeš, ale druhá strana je nemusí akceptovat, protože vystupuješ v roli PFO a nikoliv v roli FO, ...
A presne tohle neni pravda. Urad te nemuze jako fyzickou osobu ovcana kontaktovat pres DS podnikatele, ale naopak to akceptovat je povinen.

Ale stát to samozřejmě vůbec neulehčuje tím, že DIČ je u PFO ve formátu "CZ<RČ>", což je jednak naprosto matoucí a jednak demence na druhou, protože jako OSVČ vytrubujete svoje RČ úplně všem.
Pokud je osvc zaroven platcem DPH tak je jeho RC zaroven DIC, ktere musi uvadet na fakturach, coz je mimochodem uz drahne let ilegalni, ale stat stim dlouhodobe nic nedela, protoze prohlasit, ze se dicem stava cz+ic (stejne jako u vsech firem) ... je nad schopnosti byrokratu.

Ještě poznámku.

Když se odesílá elektronické hlášení o nějaké dani - například DPH, tak je třeba nějakým způsobem ověřit, že to odesílá ten správný subjekt. A když to odesílá OSVČ, tak to ověření může provést asi "miliónem" způsobů, které všechny fungují, ale jenom ten jeden, datová schránka PFO, souvisí s tím "podnikáním". Takové MojeID nebo soukromé bankovní identity o tom vůbec nic netuší, ale přesto to státu stačí, aby se "hmotná" fyzická osoba identifikovala i jako "nehmotná" podnikající fyzická osoba.
Pripadne tomu statu v mnoha pripadech staci, kdyz dostane papir, na tom papriu jsou kdovi ci  nacionale ...a nejaka cmaranice, ktere se rika podpis ... a  nijak se nic neoveruje. To plati zejmena pro vsechna hlaseni prave treba OSVC.

Mě by třeba, ať zůstaneme v kontextu komunikace s OSPOD, docela zajímalo co se bude dít, když třeba v nějakém úředním řízení, řekněme třeba při sporu o dítě, budu se soudem komunikovat z DS PFO. Protože těžko moje živnost bude mít rodičovská práva.
Nebude se dit vubec nic, viz vejs. Tvoje komunikace smerem ke statu muze byt vedena jak z DS ovcana tak z DS podnikatele. Neplati to jen opacne, tzn pokud te ourad k necemu vyziva, musi to dorucit do spravne DS.

Ovsem je zaroven treba rict, ze i kdyz to ourad (to neni zadna vyjimka) doruci blbe, a ty na to reagujes, tak se to zacne povazovat za platne doruceny.

3
Server / Re:DMARC/SFP a hlavička Return-Path
« Poslední příspěvek od Filip Jirsák (forum) kdy Dnes v 08:58:40 »
SPF kontrola nepracuje s hlavičkou From:, ale s adresou mail sender.
Samotné SPF ano. Ale dnes se SPF používá jako součást DMARC, kdy doména validovaná přes SPF nebo DKIM vstupuje do validace adresy From e-mailu – DMARC Alignment kontroluje, zda doména ve From odpovídá doméně SPF nebo DKIM.

Můžete narazit i na názor, že při přeposílání má přeposílající převzít za tento mail odpovědnost tak, že adresu mail sender změní na svoji vlastní. (A adresu From: ponechá beze změny.) To je také možné řešení.
K tomu také slouží SRS. Přepisovat obálkového odesílatele je správně, špatně je naopak to, že se na to dříve kašlalo. Obálkový odesílatel je ten, kdo je odpovědný za doručení daného e-mailu a komu se tedy musí vracet případné chyby.

Představte si, že budu mít třeba adresu josef@example.org, a všechny e-maily na ní směrované budu přeposílat na josef@example.com. Když nebudu přepisovat obálkového odesílatele, přepošle se e-mail na josef@example.com s původním odesílatelem, třeba alice@example.net. Když bude problém s doručením do cílové schránky, třeba bude plná, pošle se na alice@example.net chyba o nedoručení na josef@example.com. Ale co má Alice s tou chybou dělat? Ona žádný e-mail na adresu josef@example.com neposílala, nemusí vědět, komu ten e-mail patří.

S následným nástupem DKIM, DMARC a kontroly alignmentů všeho druhu mají ale obě dvě řešení své nedostatky.
Jaké nedostatky má DKIM? Pokud někdo nepřepisuje hlavičku v e-mailu, které přepisovat nemá, tak DKIM podporuje z principu všechny možné scénáře použití e-mailu.

Obvykle ale předpokládají, že DMARC politika odesilatele nevyžaduje současně splnit SPF i DKIM.
Ona to ani vyžadovat nemůže. Jediný problém nastává, pokud někdo používá jenom SPF.

Chcete-li plnit DMARC zcela důsledně, tak dojdete k závěru, že adresy From:, mail sender a  doménové jméno z DKIM podpisu musejí být prakticky stejné, resp. ve vzájemném souladu/alignmentu.
Pro důsledné plnění DMARC stačí používat DKIM.

SPF je přežitek z doby, kdy byla snaha vyhnout se kryptografii a validovat e-maily podle toho, kdo je odesílá. Naráželo to na dva problémy – jednak spousta serverů při přeposílání neměnila odesílatele v obálce e-mailu. To se dá spravit třeba právě přes SRS. Ale hlavně tím byla validovaná obálková e-mailová adresa, kterou uživatel nevidí. Uživatele zajímá From z e-mailu. Mohlo to teoreticky fungovat tak, že důvěřujete tomu, kdo e-mail přeposílá, a že on validoval SPF. Jenže někdy chcete přeposílat všechno, i spam a e-maily s nevalidním SPF, takže by to přeposílající musel nějak signalizovat. A na to standardní mechanismus není.

Tohle se snažil napravit DMARC alignment, který ovšem při použití se SPF zase rozbil přeposílání, při kterém From z e-mailu neodpovídá obálkovému odesílateli.

Používejte při vytváření e-mailu DKIM, pak s e-maily nebudou problémy při DMARC validaci ani při přeposílání.
4
Vývoj / Re:Prečo nie je Lisp populárnejší?
« Poslední příspěvek od Radek Miček kdy Dnes v 08:23:53 »
Kód: [Vybrat]
string::10: collection not found
  for module path: plot
  collection: "plot"

Pardon, je třeba ještě nainstalovat plot:

Kód: [Vybrat]
pkg install racket -y
raco pkg install --skip-installed --auto plot

racket -e '(require plot) (plot-file (function sin 0 (* 2 pi) #:label "y = sin(x)") "sine.png")'
convert sine.png sine.gif
5
Hardware / Re:Chování nabídky napětí USB-C nabíječky s PD
« Poslední příspěvek od Vít Šesták (v6ak) kdy Dnes v 08:01:56 »
S nabíječkama z IKEA za pár stovek tu asi budu vypadat trošku posh, ale oproti těm z Alíku mám větší důvěru, že nevyhořím, i že budou fungovat.

Ad 5V v USB C – upřesním: Je naprosto OK, že těch 5V bude na samci, který není k ničemu připojen. (To je běžná situace u USB A-C kabelů.) Ale toto napětí nesmí být na samici, dokud si to protistrana nevyjedná. Důvod je jednoduchý – představte si propojení dvou USB C zdrojů kabelem, případně totéž u USB A a USB C zdroje. Pokud na USB C samici bude 5V (±5%), pak se oba zdroje propojí. Ne vždy to bude problém, ale může tu být rozdíl až 0.5V, pak silnější zdroj bude zkoušet krmit ten slabší.

Krmit z USB něco bez vyjednání proudu je problém, zvlášť pokud jsme nad 5V 0.1A. Zdroj může omezit proud a koncové zařízení by to mělo respektovat.
6
Odkladiště / Re:OSVČ a komunikace s OSPOD
« Poslední příspěvek od benz.abdulaziz kdy Dnes v 07:37:48 »
Neexistuje žádná PFO, která by se jakkoli lišila od FO.
Každá PFO se od FO liší v tom, že PFO se identifikuje IČ a FO pak RČ. A od toho se odvíjí další věci, např. již zmiňovaný nákup zboží (podnikatel vs. spotřebitel).
7
Hardware / Re:haluze Chování nabíječky s PD
« Poslední příspěvek od CFM kdy Dnes v 06:12:51 »
Co je totot zač?
Sjůůpr dodgy? Pošli to Danykovi na rozebrání, ať se mrknem, jak daleko od smrti či vyhoření jsi byl:
https://www.youtube.com/@DiodeGoneWild/search?query=charger
8
Vývoj / Re:Prečo nie je Lisp populárnejší?
« Poslední příspěvek od qelurg kdy Dnes v 05:35:28 »
Kód: [Vybrat]
pkg install racket -y

racket -e '(require plot) (plot-file (function sin (- pi) pi #:label "y = sin(x)") #:out-file "sine.png" #:out-kind '"'"'png")'
convert sine.png sine.gif

Díky, že jsi ukázal, proč je Python populární a Lisp (Scheme) není.

Kód: [Vybrat]
~ $ bash test.sh
Testing the available mirrors:
[*] (1) https://packages.termux.dev/apt/termux-main: ok
Picking mirror: (0) /data/data/com.termux/files/usr/etc/termux/mirrors/europe/packages.termux.dev
Get:1 https://packages.termux.dev/apt/termux-main stable InRelease [14.0 kB]
Get:2 https://packages.termux.dev/apt/termux-main stable/main aarch64 Packages [538 kB]
Fetched 552 kB in 2s (357 kB/s)
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
367 packages can be upgraded. Run 'apt list --upgradable' to see them.
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following packages were automatically installed and are no longer required:
  rust-std-aarch64-linux-android zziplib
Use 'apt autoremove' to remove them.
The following NEW packages will be installed:
  racket
0 upgraded, 1 newly installed, 0 to remove and 367 not upgraded.
Need to get 5656 kB of archives.
After this operation, 34.1 MB of additional disk space will be used.
Get:1 https://packages.termux.dev/apt/termux-main stable/main aarch64 racket aarch64 8.18 [5656 kB]
Fetched 5656 kB in 4s (1391 kB/s)
Selecting previously unselected package racket.
(Reading database ... 59252 files and directories currently installed.)
Preparing to unpack .../racket_8.18_aarch64.deb ...
Unpacking racket (8.18) ...
Setting up racket (8.18) ...
string::10: collection not found
  for module path: plot
  collection: "plot"
  in collection directories:
   /data/data/com.termux/files/home/.local/share/racket/8.18/collects
   /data/data/com.termux/files/usr/share/racket/collects
   /data/data/com.termux/files/usr/share/racket/pkgs/base
   /data/data/com.termux/files/usr/share/racket/pkgs/racket-lib
  location...:
   string::10
  context...:
   show-collection-err
   perform-require!
   for-loop
   loop
   expand-capturing-lifts
   temp98_0
   temp71_0
   compile
   temp65_0
WARNING: The convert command is deprecated in IMv7, use "magick" instead of "convert" or "magick convert"

convert: unable to open image 'sine.png': No such file or directory @ error/blob.c/OpenBlob/3596.
convert: no images defined `sine.gif' @ error/deprecate.c/ConvertImageCommand/3368.
9
Software / Re:Nekorektní chování BTRFS
« Poslední příspěvek od RDa kdy Dnes v 00:28:27 »
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.

A ted nam tedy vysvetlete, proc by (specificky kvuli) CoW ten FS mel byt mene vykonny, kdyz se pouze zapisuji nova data??

U modifikace souboru (a la databaze) je snizeni vykonu jasny - namisto inplace write/update se udela kopie bloku z daneho souboru a musi aktualizovat reference ve stromu.
10
Software / Re:Nekorektní chování BTRFS
« Poslední příspěvek od _mbily kdy Dnes v 00:00:31 »
To volné nedotknutelné místo prostě berte jako cenu či daň za provozování takového typu filesystému. Ať už je to btrfs, zfs, ceph a určitě ještě řada dalších...
Stran: [1] 2 3 ... 10