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 - Martin Sivák

Stran: [1] 2 3 ... 11
1
Software / Re:SW k uchovávání informací, poznámek
« kdy: 26. 02. 2024, 20:32:51 »
Používám Joplin (https://joplinapp.org/) - markdown, pluginy, web clipper. Funkční offline, ale umí synchronizaci přes Nextcloud a další služby. Podporuje end-to-end šifrování.

2
Odkladiště / Re:Domácí archivace dat
« kdy: 26. 02. 2024, 13:41:02 »
Vojín Kotas, já mám dotaz:
Kolikrát jsi hrábnul do historie aby sis ty fotky prohlédnul nebo někomu ukázal (kromě situace že bys tím chtěl nějaké návštěvě taktně naznačit, že je nejvyšší čas aby se zvedla a odešla)?

Fotky se archivují na papír. A fotoalba jsme si prohlíželi sami i s příbuznými vícekrát. Na to mi stačí vybrané a upravené fotky.

Do historie se také sahá například, když chystáte nějakou zábavu na svatbu nebo vzpomínku na pohřeb. A na to už se hodí negativy, protože nějaká důležitá fotka nemusela projít sítem pro běžné prohlížení v albu.

Takže ano, fotografický archiv mám taky. Provozní v NASu (a starém NASu v jiné lokalitě) + mírně probraný Blu-ray (M-disc).

4
Problém je, že nyní jsem někde zaměstnaný. Ve firmě, co nedělá ve stejném oboru, ve firmě, která absolutně nebude mít zájem o ty zakázky, co se chystám udělat. Ale současně pracuji ve firmě, jejíž šéf mi nikdy nedovolí udělat to bokem, pokud bych se ho zeptal.

Proč by měl zaměstnavatel z jiného oboru mít nějaký vliv na to, jestli budete dělat práci navíc? Na základě čeho by Vám to mohl zakázat?

Pokud si splníte svoje povinnosti v HPP, tak klidně vedlejší příjem mít můžete. Obvyklá překážka je zákaz konkurování zaměstnavateli, ale to jste vyloučil. Takže nevidím jiný problém než časový. Jak budete řešit schůzky se zákazníky, když budete přes den v HPP práci?

5
Jak jinak chcete říct manažerovi, že Vás z práce víc baví nějaká konkrétní oblast? Že se chcete sám stát manažerem (nebo naopak nechcete)? Že chcete více nebo méně kontaktu se zákazníkem? Že Vás baví/nebaví učit, přednášet, ...
Pokud je otázka na TL (ale i na manažera přímo nad ním), tak pokud je k tomu potřeba 1:1, tak správný způsob bych viděl někde směrem na HR podepsat výstup a jít na IT odevzdat notebook.

Normálně na tohle běžně funguje interní teamová komunikace, ať už nějaké kecátko, nebo se chodí na pivo popř oběd, firemní chlastačky apod. Ale jako představa, že TL celej rok netuší, co jeho lidi chtěj dělat... no pardón.

Asi jste nedělal v distribuovaném korporátním týmu. Oběd a pivo fakt nehrozí. Navíc tam jsou i další lidi, takže není vhodné probírat některé citlivější aspekty práce (krom obchodních tajemství třeba i to, že se s někým dělá fakt blbě).

Nicméně máte pravdu, že ten 1:1 má probíhat častěji než jednou za rok. A formálně rezervovaný čas v kalendáři je efektivnější, než náhodné diskuze na kecátku. Protože se na to oba můžeme psychicky i argumentačně připravit a je na to klid.

Já se s šéfem bavím několikrát denně. O projektech, prioritách, zákaznících atd. Ale každý týden mám půlhodinu vyloženě vyhrazenou na diskuzi o sobě. Funguje to dobře.

6
Plánování kariéry může být užitečný nástroj, ale musí se správně uchopit.

Jak jinak chcete říct manažerovi, že Vás z práce víc baví nějaká konkrétní oblast? Že se chcete sám stát manažerem (nebo naopak nechcete)? Že chcete více nebo méně kontaktu se zákazníkem? Že Vás baví/nebaví učit, přednášet, ...

Vůbec nejde o okamžitou změnu, jedno školení nebo učení se nové verze PHP. Stejně tak je relativně hloupost řešit konkrétní úkoly a počty bugů na čtvrtletí, to nějak jde až u seniorních lidí, kteří vedou projekty. Ti pod nima prostě plní zadání jak je dostanou a technologie se učí jak je potřeba.

V té korporaci ale nemusíte sedět 30 let pořád na stejné židli ve stejném týmu. Na základě těch informací z 1:1 a performance review Vás třeba šéf může doporučit na nový projekt, když se taková příležitost naskytne. Nebo Vám v průběhu roku zadávat vhodné úkoly, abyste pracovali s někým s potřebnými zkušenostmi, něco se tím naučili, posunuli se tím "zábavným" směrem a byli připraveni na šanci v té oblasti až přijde.

Argument "chci dělat dobře svoji práci" může být v danou chvíli pravda, ale v čase se to mění. Za 5 let Vás ta stejná práce pořád dokola už bavit nebude. A šéf musí vědět co chcete. Něco pozná, ale detaily mu musíte říct, protože věštit neumí.

Taky můžete dostat nového šéfa.. a ten nebude znát Vaši historii a dlouhodobé zájmy, pokud nebudou zapsané.


Pochopitelně můžete tu hru hrát jenom jako, vyplníte nějaké blbosti a dostanete garbage in -> garbage out. Je to jen o tom jaké si to uděláte. Na blbého šéfa samozřejmě můžete narazit taky..

7
Software / Re:IM protokol maskující, kdo s kým píše
« kdy: 24. 01. 2024, 19:31:08 »
Nepomuze ti ani to, ze protistrana je offline, protoze kB prisel, kB odesel.

Takhle to ovšem přesně vypadat nebude. Představte si třeba (šifrované) SMTP + IMAP.

1) Část té komunikace bude příkazová - autentizace, vypiš seznam zpráv, stáhni zprávy atd.
2) Stahované zprávy budou agregované do minimálního množství paketů
3) Šifrování udělá padding na velikost bloku

Takže jediné co uvidíte je sekvence paketů s velikostí dle MTU a pak jeden menší. Naprosto nepoznáte jestli to byla jedna zpráva nebo několik.

A to nemluvím o možnosti mít něco jako HTTP/2 multiplexing, kde se streamy prolínají v rámci jednoho (šifrovaného) přenosu.

8
Software / Re:IM protokol maskující, kdo s kým píše
« kdy: 24. 01. 2024, 11:35:10 »
To nie je pravda, uvidi aj casovu korelaciu posielanych sprav, a to tu cely cas riesim, utocnik nemusi poznat obsah sprav aby vedel kto s kym kedy a ako casto, z coho sa da vytazil vela informacii.

Neuvidí, protože jediné co uvidí jsou šifrované pakety na store & forward server, který používá mnoho lidí. Takže nikdy nepozná komu ta zpráva byla předána. Server ji klidně může zadržet do doby, než se druhá strana připojí a vyžádá si nové zprávy.

9
Software / Re:IM protokol maskující, kdo s kým píše
« kdy: 22. 01. 2024, 14:09:26 »
Pre to by ma zaujimalo, ci tento problem uz niekto neriesil.

Samozřejmě, že řešil. I v offline světě. Přečtěte si nějaký špionážní román.. mrtvé schránky, inzeráty, moderněji třeba internetová fóra, několik postupných spojek atd. Ty principy anonymizace se v online světě až tak neliší.

Pokud věříte serveru, tak nepřítel uvidí jen, že komunikujete se serverem, stejně jako mnoho dalších lidí. Ale zašifrovaný obsah zpráv neuvidí. Tj ani hlavičky. Takže nepozná kdo se baví s kým. Případně ten důvěryhodný server může být jen endpoint pro privátní VPN. Tam už pozná jen, že posíláte nějaký traffic. Ale nepozná komu.

Zobecněním VPN ve VPN (protože nevěříte ani serveru) a více postupných anonymizačních kroků je ten Tor.

Musíte mít nějaký nenápadný "telefonní seznam". Vy pošlete šifrovanou zprávu do sítě a ona po trojím přebalení někde vyplave. Ideálně není jak ze vstupu do Toru poznat kam jste ji poslal a stejně tak není na výstupu poznat kdo ji poslal. Interní metadata jsou šifrovaná a nečitelná.

Implementací může být více, ten zmíněný Tox je jedna z nich: https://tox.chat/

10
Software / Re:IM protokol maskující, kdo s kým píše
« kdy: 22. 01. 2024, 11:14:06 »
tor riesi iny problem

tor řeší přesně ten zadaný problém, pokud používáte protokol na bázi peer to peer. Třeba federovaný Jabber, kde mají A, B a C vlastní servery.

Co neřeší a ani nemůže, je Vaše důvěra v server, který zprostředkovává výměnu metadat pro spojení. U Jabberu je to DNS + servery A a B (pro rozlišení lokálních uživatelů).

Nebo i jednodušeji. SMTP. Také federované P2P. Ale na úrovni serveru už toho lokálního uživatele neutajíte, musíte nějak určit do jaké to půjde schránky.

11
Hardware / Re:Regulace nabíjení trvale připojeného notebooku
« kdy: 07. 12. 2023, 17:57:14 »
K OP: Proč to chceš cyklovat 10-90? Pokud ti to běží 24x7 v zásuvce, tak ten stroj nech být a na baterku nesahej: Používání baterky ji zestárne mnohem rychleji, než když bude nepoužívaná sedět ve stroji na 100 %.

To bohužel taky není ideální. Lithiové baterie nemají rády plné nabití. Degradují. Lepší je to zastavit na těch cca 80% (3.8 V jak píšete).

Pokud tomu chceš pomoct, tak horní hranici nabíjení nastav na 3.8 V, bez ohledu na to, kolik je to ukazovaných procent, ale tak jako tak s tím necykluj.

To bohužel obvykle nejde. Lenova třeba umí jen procenta... leda by na to byl nějaky aktivní skript co čte statistiky

12
Sítě / Re:Mikrotik - 1 hlavní, 2 Mikrotik vedlejší
« kdy: 03. 07. 2023, 13:23:45 »
Koukam ze dorazil dalsi z mistnich odborniku ... ktery ovsem nema poneti ani o bezpecnosti ani o technickych aspektech. Broadcast domain ti nic nerika ze? A ne kazdy chce, aby si kolemjdouci browsali po jeho discich.

Moc to komplikujete. Jací kolemjdoucí? Tady se nejpíše jedná jen o pokrytí druhého patra pro potřeby rodiny. Wifi je (doufám) zaheslovaná.

Oddělení provozu nikdo v zadání nepožadoval. Krom toho, laptopy a mobily členů rodiny mají předpokládám mít přístup k NASu a tiskárnám odevšad z ethernetu i wifi.

Mám to úplně stejně.

Druhý mikrotik má zjednodušeně:

- vypnutý dhcp server
- přehozený port 1 z WAN do LAN a propojený do bridge s ostatními
- (v mém případě tedy komplikovaněji s tagováním vlan, protože já oddělení sítí provozuju)
- nastavený CAPsMan klient

13
Citace
Jenže žádný z těch 274 balíčkovacích systémů (a tolik jich zase není) neřeší nezávislost desktopových aplikací na jádru systému. Takže každý uživatel pak musí řešit, že si aplikaci nemůže pustit v té verzi, kterou potřebuje.

Tohle dnes řeší minimálně 3 balíčkovací systémy - Appimage, Flatpack a Snap. Každý z nich má samozřejmě nějaká plus a nějaká mínus. Vy preferujete Flatpack, ale někdo jiný Snap a další zase Appimage.

Máte pravdu, na Snap jsem zapomněl. Canonical ten jeho "App store" drží bohužel dost "uzavřený".

Appimage se neinstaluje a typicky nemá žádnou integraci se systémem balíčků, je to takový ekvivalent DMG z OS X.

O Flatpaku už jsem mluvil. Je zaštítěný Free Desktopem, nativní v Gnome, umožňuje repozitáře třetích stran... takže chápete proč ho mám raději než Snap. (Ale uživatelé Ubuntu by možná mluvili jinak)

Výsledek pak je, že uživatel potřebuje 4 (se systémovým mechanismem - RPM/DEB/...) různé systémy pro instalaci programů.

RPM/DEB se postupně ukázaly jako nevhodné pro rychle se vyvíjející desktopové aplikace. Obzvláště je to patrné na tom Debianu, který je hodně konzervativní. Provozovat stable základ a zároveň aktuální unstable/testing aplikace není až tak úplně triviální.

Fedora měla zase jiný problém, upgrade každého půl roku, často komplet překopané knihovny..

A obojí jak RPM tak DEB vyžaduje práva administrátora pro instalaci aplikací. Do příchodu AppImage byly jedinou uživatelskou možností statické binárky nebo configure/make do lokálního prefixu.

Navíc v dnešní době malware je poněkud riskantní instalovat věci ze zdrojáků. I ty AppImage jsou dost na hraně.

Flatpak nebo Snap tyto problémy řeší, poskytují sandbox s omezením práv aplikace.

Citace
NPM, CPAN, pip, cargo a podobně nejsou konkurencí.
Těžko říct, jestli to nazývat konkurencí, ale rozhodně to jsou další balíčkovací systémy, které musí uživatel mít, pokud si chce instalovat nějaký program. Třeba spustit si běžný moderní(čti: hipsterský) JS program z Githubu je bez NPM prakticky nerealizovatelné. A dtto pro Python a PIP.

To je asi tak stejná úroveň, jako nutnost použít cargo pro nainstalování závislostí Rust zdrojáků. Tohle je typicky vývojářské použití a většina obyčejných uživatelů npm používat nebude (osobně mi pár _Gigabyte_ javascriptových zdrojáků u malého webového projektu přišlo dost šílené).

Pip / Virtualenv pro Python jsou na tom podobně. Obzvláště ve chvíli, kdy uděláte upgrade systémového Pythonu a venv prefixy přestanou fungovat, protože symlinky jsou na konkrétní verzi, která zmizela.

14
Kdyby skutečně šlo o principy, tak v Debianu není třeba SQLite, asi nejznámější příklad Open-Source, not Open-Contribution SW co v Debianu je.

Ale SQLite přijímá patche

"the project does not accept patches from people who have not submitted an affidavit dedicating their contribution into the public domain."

stačí jen "podepsat" formu CLA. Jenže gpxsee toto neumožňuje (na webu má jen vágní komentář, že možná někdy..).

15
Ten problém je ale právě v tom, že funguje jinak. Jinak než těch 274 dalších balíčkovacích mechanismů, které by preferoval zase někdo jiný. Pokus nahradit DEB/RPM, Appimage, NPM, CPAN, ..., pomocí Flatpacku opravdu neskončí jedním univerzálním standardem...

Jenže žádný z těch 274 balíčkovacích systémů (a tolik jich zase není) neřeší nezávislost desktopových aplikací na jádru systému. Takže každý uživatel pak musí řešit, že si aplikaci nemůže pustit v té verzi, kterou potřebuje. A to nemluvím o tom, že musí mít práva instalovat balíčky.

AppImage je konkurence Flatpaku, ale neumí updaty, neumí Runtimes atd. NPM, CPAN, pip, cargo a podobně nejsou konkurencí. Systémové knihovny by měly být zabalené, desktopové (nezávislé na systému) si to nějak musí zařídit a pro vývoj se dá instalovat jiná sada knihoven pro každý projekt.

Takže ve skutečnosti by desktopová aplikace dneska vůbec nemusela podporovat třeba RPM, protože Fedora podporuje Flatpak ve všech spinech. A možná ani DEB, protože Ubuntu zase preferuje AppImage...

Stran: [1] 2 3 ... 11