Příspěvky

436

Studium a uplatnění / Re:Fakturace do zahraničí (Kanada) jako OSVČ

« kdy: 30. 07. 2020, 09:08:09 »

To se týká EU a jmenuje se to "identifikovaná osoba" (§ 6g a násl. ZDPH).

Ano, to je ono, díky.

Jenom nechápu tohle:

§ 6h

Osoba povinná k dani se sídlem nebo provozovnou v tuzemsku, která není plátcem, je identifikovanou osobou ode dne přijetí zdanitelného plnění s místem plnění v tuzemsku od osoby neusazené v tuzemsku, pokud se jedná o

a) poskytnutí služby,

b) dodání zboží s instalací nebo montáží, nebo

c) dodání zboží soustavami nebo sítěmi.

Tady je "neusazené v tuzemsku", narozdíl od okolních paragrafů, kde je explicitně "členský stát". Opravdu to tedy platí jenom pro EU? Pokud prodám třeba software mimo EU, tak se identifikovanou osobou ani plátcem nestanu?

Je to hrozně komplikované a je tam spousta pojmů, které laik jako já není schopný v rozumné době rozklíčovat

437

Studium a uplatnění / Re:Fakturace do zahraničí (Kanada) jako OSVČ

« kdy: 30. 07. 2020, 08:16:23 »

Pak se může stát, že budete muset být plátce DPH (např. při překročení obratu), nebo budete chtít být plátce DPH.

Měl jsem za to, že když právnická nebo fyzická osoba přijímá peníze ze zahraničí (mimo EU?), automaticky se stává plátcem DPH. To už neplatí, nebo takhle striktně nikdy neplatilo a je k tomu potřeba ještě něco?

Vím, že se tady kdysi řešil nějaký speciální druh registrace, jejíž název si už nepamatuju, po které mělo být možné fakturovat do zahraničí a zároveň se plátcem DPH nestát. Ten název by něco jako "registrovaná fyzická osoba" nebo tak nějak.

438

Studium a uplatnění / Re:Office a remote práce po pandemii

« kdy: 29. 07. 2020, 01:57:49 »

Ještě nikdy se ti nestalo, že jsi o něčem pracovním nezávazně kecal s kolegou u oběda a o týden později se ti to hodilo v projektu?

Stalo se mi třeba i to, že jsem četl nějaké teologické pojednání a pak se mi to hodilo v informatice.

A co z toho plyne? Že je potřeba, aby informatici chodili do kostela na kázání? Asi se shodneme, že to z toho neplyne Takže za DÚ si každej promyslíme, v čem je ta otázka chybná/zavádějící.

439

Studium a uplatnění / Re:Office a remote práce po pandemii

« kdy: 28. 07. 2020, 14:58:37 »

Nepochopil. Nemluvím o "oficiální" komunikaci, ta je opravdu relativně řešitelná. Mluvím o té "neoficiální".

A já mluvím o tom, že nic z toho, co člověk pro práci potřebuje nesmí probíhat "neoficiální" komunikací. Pokud se tak děje, je to špatně a pak samozřejmě remoting zhavaruje.

440

Studium a uplatnění / Re:Office a remote práce po pandemii

« kdy: 27. 07. 2020, 14:25:08 »

spousta jich bude stále proudit jen offline a remote člověk bude mít vždycky značnou informační nevýhodu.

Ale jo, já to nepopírám, lišíme se asi jenom v tom slově "značnou" a v hodnocení příčin. Já jsem zažil dobu, kdy náš semi-remote tým fungoval dost špatně. Informace proudily přesně tak, jak říkáš. Když člověk nebyl osobně na poradách, byl mimo. A pak jsme najali výborného teamleadera, který zavedl základní štábní kulturu - zápisy z porad, dokumentace všech zásadních interních věcí (API, ontologie apod.), code reviews, denní "standupy" a jednou za delší čas retrospektivy. A najednou je ten problém s "remote outsidery" minimální - protože prostě důležité informace se zásadně nepředávají online, ale povinně offline...

Jistě, nemůžeš houknout přes stůl na kolegu "prosímtě, jak se tohle v gočku dělá?", ale to není žádný velký problém, prostě si to přibližně stejně rychle vygooglíš a když je to něco složitějšího, nehoukneš přes stůl, ale přes Slack...

441

Studium a uplatnění / Re:Office a remote práce po pandemii

« kdy: 27. 07. 2020, 12:30:06 »

Tohle není problém s částečně remote lidma, ale obecný problém s remote.

Ne, to je problém v rozdílu mezi remote a neremote. Pokud je remote jen jeden, musí stejné komunikační prostředky používat všichni (pokud ten jeden není mimo team, nemá nějakou vlastní práci, s ostatníma nesouvisející).

Typicky dva lidi řeší nějaký problém, zaslechne to náhodou třetí, který v hovoru ani není a řekne jim "Tohle jsem řešil nedávno, to musíte tak, tak a tak". Online budou komunikovat jen ti dva a ten třetí se o tom nedozví, aby jim poradil a oni neví, že se ho mohou zeptat.

Tohle je trochu problém, ale ne moc. My třeba máme denní "standupy", takže člověk tak nějak tuší, co kdo kdy řešil a koho se zeptat. Pokud neví, tak prostě napíše do Slack kanálu "hele, řeším to a to, nemáte někdo hint?"

Samozřejmě to bude problém u týmů nad dvacet lidí, ale to je pak vůbec otázka, jestli tým nad dvacet lidí (bez jakéhokoli dělení) dává nějaký smysl

442

Studium a uplatnění / Re:Office a remote práce po pandemii

« kdy: 27. 07. 2020, 05:51:53 »

Co ostatní?

"Už trošku zaběhlejší startup", odjakživa full remote, porady face to face jednou za 14 dní. Víceméně žádná změna, jenom po dobu největšího peaku jsme i ty f2f porady změnili na remote.

Z první ruky mám informace o tom, že v IBM na jedné konkrétní pozici ("poloajťácké") se z HO dva až třikrát týdně stal trvalý HO (což ale u nich není nic neobvyklýho, jenom to prostě zřejmě rozšířili na víc pozic).

Korona-lockdown to umožnil firmám vyzkoušet a kde se jim to povedlo, tam to asi teď opravdu bude běžnější.

IMHO by bylo hlavně dobře, kdyby firmy, kde se jim to nepovedlo, začaly pomalu krachovat, nebo se jim aspoň výrazně snížily marže, protože ve 21. století nebýt schopen rozjet v IT full remote, to ve většině případů bude znamenat, že management je totálně neschopný.

443

Studium a uplatnění / Re:Office a remote práce po pandemii

« kdy: 26. 07. 2020, 19:47:51 »

Pokud je někde podobné vlákno živé v posledním pár měsících, prosím dejte link. května.

https://forum.root.cz/index.php?topic=23242.msg333094#msg333094 (košatá diskuse se spoustou vedlejších témat)

444

Vývoj / Re:Přerušení v Linuxu

« kdy: 26. 07. 2020, 10:17:07 »

Si to jednou zkus - problem neni napsat kod - ten udelas treba jednou (pokud jsi sikovnej a neudelas tam moc chyb), ale pak pro kazde zarizeni kde to bezi (rekneme RPi, Beaglebone, a ruzna cina) musis vytvorit ty upravy DT - coz je softwarova analogie k toho jak si ty dratky v hw pripojil.

DT trochu znám, před nějakýma cca dvěma lety jsem s ním musel cosi řešit v Buildrootu s custom kernelem.

Na tyhle jednoduchy veci nefunguje plug & play (to se nahrazuje tim DT) a kdyz se podivas na situaci kde PnP funguje (USB) a presto se voli psani userspace driveru (skrze libusb,libhid) - musi ti byt jasne ze psat neco v userspace je omnoho jednodussi. Muzes si volit jazyk, chyby ti nezpusobi pad OS, muzes resit veci interaktivne. Snad tohle postaci..

Tohle mi nepřijde jako pádná argumentace ze dvou důvodů:
1. předpokládám, že tazatel to chce pro jedno zařízení a jednu desku, že to je nějaký custom projekt
2. důvody, proč se různé věci dělají spíš v userspace, můžou být úplně jiné a v daném případě neplatné

Takže tohle mě moc nepřesvědčilo. Kdybys řekl "věř mi, mám to vyzkoušené, tohle je lepší cesta", mělo by to pro mě (od tebe) větší váhu

445

Vývoj / Re:Přerušení v Linuxu

« kdy: 26. 07. 2020, 10:04:41 »

Kdyby to chtel psat in-kernel jak by to rad Mirek

Já jenom dodám, že o tom prakticky nic nevím, takže jenom čistě laicky mi přišlo, že když mám v kernelu připravený základ, je snazší nad ním napsat nějaký tenký wrapper a vyexportovat si jednoduché jednoúčelové zařízení, se kterým už pak práce v userlandu bude triviální.

Spíš jsem se ptal, proč by se to tak udělat nemělo, rozhodně jsem se s tebou o to nechtěl hádat, na to jsem fakt v téhle oblasti úplný laik

446

Vývoj / Re:Přerušení v Linuxu

« kdy: 24. 07. 2020, 21:38:01 »

jenom ho vyuzivaji jako jednu z komunikacnich cest.

No dyt.

447

Vývoj / Re:Přerušení v Linuxu

« kdy: 24. 07. 2020, 20:24:56 »

Psat ovladac do jadra ma smysl jedine kdyby to zarizeni spadalo do existujicich trid zarizeni, ke kteremu existuje standardni linuxove API.

Já jsem dotaz pochopil tak, že to je přesně ten případ. V kernelu už základ SPI je, chci si tam jenom dodělat ten mechanismus probuzení userlandu.

448

Vývoj / Re:Přerušení v Linuxu

« kdy: 24. 07. 2020, 18:43:19 »

SPI i I2C jsou master/slave zbernice, a jinak nez pollingem se s takovyma periferiema neda bavit. Pokud chce zarizeni neco rict, muze trpelive mlcet, az dostane slovo (polling), nebo se ozvat dodatecnym, out of band, signalem - prerusenim, na zaklade cehoz vyvola pozornost mastera aby ho zkontroloval.

Jasne, ale tohle je/bude v jádře, ne v userspace.

Blokujici zarizeni se da vytvorit jedine napsanim ovladace konkretni periferie (konkretniho cipu).

Tazatel chce jenom implementovat "user space driver", protoze vyvoj a ladeni je mnohokrat jednodussi. Pokud je srozumen s reakcni dobou / latencema a nevadi to dane aplikaci, tak bych to taky tak preferoval.

Těžko může implementovat jenom "user space driver", když chce funkcionalitu, kterou žádný (?) existující kernel driver nemá.

449

Vývoj / Re:Software-only USB host

« kdy: 24. 07. 2020, 16:12:30 »

Jenom tak ze zvědavosti: proč bys to dělal, když už je dneska na trhu dostatek čipů s minimálně OTG za rozumnou cenu?

450

Vývoj / Re:Přerušení v Linuxu

« kdy: 24. 07. 2020, 15:41:31 »

Ale tazatel nechce implementovat samotne SPI, ale dodatecny notifikacni mechanizmus vyuzivajici preruseni - jakozto optimalni reseni vuci amaterismum typu busy-loop a polling! Samozrejme ze RPI ma hw SPI a linux ma sve genericke SPI API.

Já pořád nerozumím tomu, proč by měl v userlandu dělat polling.

Přijde mi, že se OP ptá z prostředka: má nějaký problém, vymyslel pro něj řešení, které neumí implementovat* a chtěl by s tou implementací pomoct. IMHO by bylo lepší, kdyby nastínil ten původní problém, třeba pro něj existuje nějaké jiné, standardní řešení.

Např. pokud by původní problém byl v tom, že nějaký hardware pomocí SPI pushuje hodnoty v nepravidelných intervalech a on na ně chce reagovat (soft)realtime, tak nepotřebuje žádné interrupty, bohatě mu stačí blokující znakové zařízení...

* to není kritika!