Příspěvky

1561

Vývoj / Re:Jakou licenci pro můj SW použít, když chci zachovat původního autora

« kdy: 06. 06. 2018, 14:34:55 »

A dá se vůbec proti takovému porušení licence nějak efektivně bránit?

Odpovím jen ne tuto část.
Efektivně se můžete bránit jedině u soudu. Soud je vždycky místně příslušný podle adresy žalovaného.

Pokud Vás poškodí někdo, řekneme, z Maďarska, nemáte jinou možnost, než ho zažalovat právě tam. K žalobě potřebujete prokázat 1) protiprávní jednání žalovaného, 2) škodu, která Vám vznikla, 3) příčinnou souvislost mezi protiprávním jednáním a škodou.

Největší překážkou bývá to, že musíte porozumět právnímu režimu země žalovaného (v praxi = najmout si advokáta z té země) a druhou překážkou je stanovit škodu, která Vám vznikla. Škodou se, aspoň podle českého právního řádu rozumí v penězích vyjádřená částka, o kterou se zmenšil Váš majetek, ale nezmenšil by se, kdyby nedošlo k protiprávnímu jednání žalovaného.

Pokud dáváte software zadarmo, pak škoda, která Vám vznikla je nulová. V tu chvíli můžete zvažovat žalobu na to, aby soud určil, že se má žalovaný zdržet protiprávního jednání, případně na nemajetkovou újmu (satisfakci).

Aspoň takto, přibližně, to bude vidět evropské právo.

V USA bude asi situace jiná, tam se víc klade důraz na satisfakci místo náhrady škody.

(Proto se také velké firmy vůbec nebojí používat open source software ve svých produktech, protože není nikdo, kdo by je žaloval, nikdo na to nemá peníze, a v případě výhry nedostane zaplacené ani náklady).

1562

Odkladiště / Re:Platby kryptoměnou v pohostinství

« kdy: 06. 06. 2018, 06:30:14 »

Z pohledu zakona o dani z prijmu se nicmene jedna o prijem, ktery je nutno zdanit. A je uplne jedno, ze jde o smenu, je to proste prijem, neco podobneho je platba faktury zapoctem.

Omlouvám se, máte pravdu.

1563

Odkladiště / Re:Platby kryptoměnou v pohostinstvi

« kdy: 05. 06. 2018, 18:22:55 »

Aj slovensky minister financii chce zdanovat kryptomeny, ale naraza prave na tento problem - podla akeho kurzu zdanovat.

Kryptoměna není měna a když ji obdržíte, není to příjem.
Směňujete jídlo za něco jiného - představte si, že za to jídlo a pití neplatíte Bitcoinem, ale třeba duhovými kuličkami.
Pokud hospodskému "zaplatíte" za jídlo kuličkami, ve skutečnosti nerealizuje příjem, ale směnil jednu věc za druhou.

Hospodský realizuje příjem až v momentu, kdy kryptoměnu promění v peníze. V ten moment dochází k příjmu a daní se podle toho, kolik korun (eur) obdržíte.

1564

Hardware / Re:Notebook po dni spánku vybitý o 85 %

« kdy: 05. 06. 2018, 07:07:14 »

Macíku, proč si kupujete Maca? Vždyť Vy ho chcete používat úplně jinak, než jak je určený. Zrovna Mac není vůbec dobrá platforma pro přizpůsobování. Ten se používá tak jak je, a tak jak umožní klikátka v preferencích. Nemusí Vám to vyhovovat, ale pak ho prostě nekupujte .

1565

Odkladiště / Re:Školení GDPR pro sekretářky, účetní a vývojáře

« kdy: 04. 06. 2018, 18:01:16 »

Potřebuji vyřešit proškolení:
- sekretářky a účetní v jednom
- webový vývojář

Sekretářka a účetní v jednom je nesmysl. To možná funguje ve firmě o dvou lidech, ale tam je celé GDPR o tom, že si řeknete se šéfem pravidla. Ve firmě o dvou lidech pak platí pravidla v tomto pořadí: 1. nechceme znát žádné informace, které skutečně nepotřebujeme, 2. ty informace, které potřebujeme, chráníme, co nejvíc to jde - mažeme neaktuální, aktuální nedáváme nikam, kde k nim může kdokoliv jiný.

Webový vývojář není správná osoba pro GDPR. Webový vývojář má dostat jasné zadání od zadavatele, včetně požadavků zmocněnce pro GDPR a těmi se řídit. Webový vývojář nemůže mít kvalifikaci cokoliv za firmu posuzovat.

1566

Software / Re:Pomoc sekretářkám - automatizované zpracování faktur

« kdy: 02. 06. 2018, 09:26:49 »

Jinak když mi mamka říkala, jaké faktury zpracovává a jak toho má hodně, tak jsem valil oči, jakou hrůzu ty malé firmy mají. 80% jejich práce by mohly dělat počítače a inf. systém. Ty lidi a firmy mají postupy zaseklé tak v 90. letech, a to už tehda existovalo OCR. Jsou tak 25 let pozadu v tomhletom. Jenže my programátoři jsme pro ně asi prostě moc drazí, západ tlačí ceny nahoru.

O to nejde, že by nešly doklady skenovat nebo parsovat. To už nějak řešitelné je (i když ne levně). Ale úplně se tím mění styl práce. V malé firmě asistentka pracuje s dokladem a zároveň, co ho zadává, dělá i další činnosti. Mimo jiné kontroluje, jestli je legitimní (tedy, jestli má být proplacen), zjišťuje na jaké středisko se účtuje, případně do jakého týmu spadá, ... Samotné přetypování dat pak dává možnost v reálném čase ověřit jestli protistrana není tzv. nespolehlivá osoba nebo jestli má zveřejněné účty pro placení DPH. Když zautomatizujete sken dokumentů a vytěžení, budete muset úplně jinak nastavit tyto procesy - a mnohdy zase o kousek složitěji.

1567

Software / Re:Pomoc sekretářkám - automatizované zpracování faktur

« kdy: 02. 06. 2018, 06:18:02 »

Je tady rozebráno víc témat, k několika se vyjádřím:

1) Automatické vytěžování dokumentů se používá, ale používá se hlavně tam, kde lze nastavit systém že VÍCE osob se zabývá vytěžováním a zadáváním faktur do systému (s automatickým vytěžováním souvisí i ruční opravy chyb a "oční" kontrola), přikládání skenu faktury do systému atd. Tyto osoby bývají v mzdově v ranku brigádníka. Poté už menší počet účetních může provádět jen odbornou práci - zaúčtovávat celé doklady a/nebo položky. Tam, kde je 1-2 účetní nemá automatické vytěžování dat valný smysl.

2) EDI používají hlavně velké firmy. Papírový doklad nemusí mít žádné ověření (náležitosti), dokonce není potřeba ani podpis osoby, ani razítko (viz zákon o DPH, ten vyžaduje pouze (vytištěné) jméno osoby, která doklad vystavila, a i z toho existuje výjimka u automaticky generovaných faktur (O2, PRE, ...)). V případě EDI jsou zákonné požadavky o dost vyšší, a obecně u jakéhokoliv elektronického dokladu je potřeba mít i elektronický podpis (který je nutné v době pro uchování dokladů 10 let minimálně 2-3x přerazítkovat). Elektronický doklad je pro malou firmu moc drahý. (Faktura v PDF není elektronický doklad, to je stále jen listina, pouze zaslaná elektronicky).

3) Pohoda je ve startovní kategorii jeden z málo softwarů na trhu. Začínající firma, nejen ta, která si chce účtovat sama, potřebuje levný software pro evidenci dokladů, pokladny, plateb. Zde Pohoda konkuruje velmi dobře. Ve vyšších verzích umí i oddělovat práva účetních od těch, co doklady zadávají apod. Dobrý účetní dokáže pracovat s jakýmkoliv softwarem, který umí vyjet rozvahu, saldo a knihy závazků a pohledávek. Pak už se dá zkontrolovat zaúčtování a je víceméně jedno, jestli je to Pohoda nebo něco jiného. Ohrnování nosu nad tím či oním softwarem není na místě, spíš to značí neochotu účetního se učit odlišné postupy. Pokud chcete Pohodu srovnávat, tak s jejími konkurenty ve stejné cenové hladině. Moc si nevyberete. Buďto se jedná o programy, které je dražší provozovat (vyšší nároky), nebo jejich ovládání odpovídá "většímu softwaru" a tudíž je pro malou firmu brzdou chodit na školení a učit se je. Reálným konkurentem je Money S3 - ale to taky není žádná výhra. Abra (FlexiBee) se koncákům špatně ovládá a dohledává se v ní. Vario? To je podle mě okrajové. Zapomněl jsem na někoho? Myslím že ne. Takže začínající / malá firma (do 50 zaměstnanců) vybírá z této čtveřice a Pohoda tento boj vyhrává. Účetní by třeba volili jinak, ale primární je zákazník a jeho práce s doklady, aby měl přehled o stavu svých závazků a pohledávek.

1568

Sítě / Re:Forward trafficu na jiný server, se zachováním původní cesty

« kdy: 31. 05. 2018, 15:37:10 »

Nemyslím si, že by NAT byl nejvhodnějším řešením. Na sledování UDP spojení na základě IP adres a portů není potřeba nic psát, je to už součástí netfilteru, stejně jako to sledování TCP spojení. A i kdybyste chtěl psát vlastní helper, není nutné psát to do jádra, conntrack helpery mohou fungovat i v uživatelském prostoru.

Pokud není v cestě NAT, pak není přeci co řešit. Paket dorazí na cílovou adresu. Jediná komplikace nastává právě v případě NATU. A to lze usuzovat z popsané situace v kombinaci s problemem

1569

Sítě / Re:Forward trafficu na jiný server, se zachováním původní cesty

« kdy: 31. 05. 2018, 15:02:40 »

Ne, týká se to obojího. Linuxový NAT nepracuje na úrovni spojení, ale na úrovni paketů. NAT si eviduje tabulku spojení (což nemusí být jen TCP/IP spojení, ale i komunikace založené na UDP, řídící a datové spojení FTP) a ke každému spojení si eviduje údaje o parametrech příchozích paketů a údaje pozměněných paketů. Na základě této tabulky pak jednotlivé pakety transformuje. Spoustu těch helperů pro sledování spojení obsahuje už Netfilter – pro FTP, SIP, DNS…

Ano, ale to jsou přesně ty helpery. Čisté UDP není jak trackovat, a musí existovat pomocníček, který conntracku poradí, jaký UDP packet souvisí s jakým. Na TCP potřebujete helper, co já vím, jen na aktivní FTP, kdy je potřeba otevřít prostup zpět na ftp-data.

Bez programování modulu jádra prostě UDP kolega neodtrackuje, není se čeho chytit.

1570

Sítě / Re:Forward trafficu na jiný server, se zachováním původní cesty

« kdy: 31. 05. 2018, 14:35:18 »

Ta druhá varianta je přesně to, co dělá NAT, ale nejsem si jistý, zda je možné nastavit limity linuxového NATu tak, aby držel tabulku spojení po dobu několika hodin. A i pokud by to uměl, nevím, jak se to bude chovat, je to daleko za předpokládaným způsobem použití.

Souhlas, co píšete, jen se to týká TCP. U TCP je navázané spojení a na routeru je jasné, který packet směrem ven souvisí s s předchozím dovnitř. U UDP žádnou takovou možnost nemáte, musíte leda napsat helper, který to z něčeho vyvěští. Buďto, třeba, z kombinace portů, nebo, třeba, z obsahu packetu (L7).

1571

Hardware / Re:Životnost serverů

« kdy: 31. 05. 2018, 14:08:10 »

No, tyhle jsou Ni-MH. Ale ani lithium není problém. Pár takových jsem navrhoval, vyresetovat ten chip je práce max. ma pár hodin (jednorázově, stačí udělat přípravek s nějakým MCU). V krajním případě se musí vyměnit ten gas-gauge, pak je otázka, na co to přijde. Ale pravděpodobně to v součku bude levnější, protože originál BBU jsou někdy tak drahé, že bych je byl schopen v desítkových sériích vyrábět levněji...

Tak to jo, souhlas.

1572

Hardware / Re:Životnost serverů

« kdy: 31. 05. 2018, 14:02:45 »

Zatím jsem to jen zkusil a nechal si babodovat články, prohodil jsem si to sám. Zase tolik jich nemáme, aby se mi vyplatilo řešit, kdo to udělá...

U lithiových baterií nestačí vyměnit články, ale musí se ještě nastavit (vyresetovat) elektronika, v krajním případě i vyměnit. Jinak nebudou dobíjet. Proto se lithiovky "složitě" repasují.

1573

Sítě / Re:Forward trafficu na jiný server, se zachováním původní cesty

« kdy: 31. 05. 2018, 13:36:08 »

přes UDP data. Nyní bych potřeboval pro určitou skupinu příchozího trafficu jedním vpn tunelem zajistit forwarding na jiný server, ovšem zároveň potřebuji, aby se vracely odpovědi těm konkrétním zařízením stejnou cestou. Ale ne jen po omezenou dobu, ta odpoěď může být odeslána i několik hodin po žádosti. Máme na to C-čkový script, který si tvoří vlastní databázi a handluje to podle ní, ale pochopitelně se nám to nelíbí, nejspíš existují mnohem elegantnější cesty.

V případě UDP nemáte jinou možnost, než do routeru doprogramovat helper, který podle učitých pravidel bude vědět, co je odpověď, a kam ji poslat.

V případě TCP je to jednoduché. Tam navážete spojení, a odpovědi v rámci spojení se vrací tam, odkud byl původní požadavek. U TCP Vám stačí zvýšit timeouty na conntracku, aby si je to pamatovalo i několik hodin.

V případě UDP neexistuje žádné spojené. Po UDP přijde paket na cílový server. Cílový server NEODPOVÍDÁ na spojení. Cílový server může jedině odeslat nový UDP paket "někam zpět". Díky tomu router neví, který paket dovnitř souvisí se kterým paketem ven. A od toho je právě "HELPER".

Helper budete potřebovat buďto v případě, že je v cestě NAT, nebo pokud chcete vybírat routovací tabulku ("stejná cesta ven").

1574

Hardware / Re:Životnost serverů

« kdy: 31. 05. 2018, 13:29:20 »

On se s tim Mm preklepl, najezdi jen 30 mm rocne.

Je to tak.

1575

Sítě / Re:Mikrotik - Switching nebo Bridging

« kdy: 31. 05. 2018, 13:27:37 »

Ahoj...
máte někdo praktické zkušenosti zda je lepší používat Switching nebo Bridging ?
Na které případy je lepší použít to a na jiné tamto.

Na bridgi lze zapnout firewall. Pak se to chová jako switch, ale umí to filtrovat mezi jednotlivými porty.
Na switchi nic takového zapnout nejde.

Pokud se nepletu, tak v nejnovějších verzích OS Mikrotika už mezi tím nerozlišují. Když přidáte do bridge porty, které lze switchovat pomocí switch cpu, tak je automaticky do toho režimu přepne. Dřív se to muselo rozlišovat ručně pomocí toho, že některé porty byly nastaveny jako master, jiné jako slave, a do bridge se pak  přidávaly jen mastery. Teď je to jednodušší.