Příspěvky

61

Studium a uplatnění / Re:Požadavky teamleadra na cíle každý rok

« kdy: 14. 02. 2024, 17:27:55 »

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..

62

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.

63

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.

64

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/

65

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.

66

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

67

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

68

Distribuce / Re:Jak dostat vlastní software do oficiálních repozitářů?

« kdy: 15. 05. 2023, 18:53:45 »

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.

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.

69

Distribuce / Re:Jak dostat vlastní software do oficiálních repozitářů?

« kdy: 15. 05. 2023, 16:23:12 »

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..).

70

Distribuce / Re:Jak dostat vlastní software do oficiálních repozitářů?

« kdy: 15. 05. 2023, 16:20:58 »

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...

71

Distribuce / Re:Jak dostat vlastní software do oficiálních repozitářů?

« kdy: 15. 05. 2023, 15:01:03 »

Opravdu na Linuxu chceme mít část SW v distribučním repu, část na Flathubu,

ANO! Jako uživatel Fedora Silverblue přesně to chci Umožňuje mi to používat aplikaci (nejnovější) jakou potřebuji na systému, který chci (třeba i starší verze..), aniž bych musel řešit závislosti.

Dnes to směřuje k tomu, že na Windows/OS X/Androidu je všechen SW v jednom App store a na Linuxu po celém internetu v podobě 275 typů balíčků... Jo, pokrok nezastavíš!

Jenže Flatpak funguje jinak. Je hierarchický, takže všechny hlavní závislosti se automaticky upgradují jen jednou pro každý Runtime (a těch je jen pár). Appimage i aplikace v App storech mají závislosti bundlované a neumí je updatovat...

Tak asi by som odporucil skusit ho dostat na flathub.

Třeba u toho zmíněného gpxsee to autor explicitně odmítl. Před pěti lety.. trošku jsem do něj šťouchnul, třeba ho to přiměje se zamyslet

V Debianu to znamená sáhodlouhé diskuze v různých "podvýborech" a kontakt s roztříštěnou, archaickou a v každé skupině jinak fungující infrastrukturou...

No ta hlavní námitka o tom, že autor gpxsee nepřijímá žádné patche je pro Debian dost zásadní:

Only localization contributions are accepted at the moment, code pull requests will be rejected.

Debian si zakládá na některých principech, které ostatní moc neřeší. A tohle je červený hadr na býka.

72

Distribuce / Re:Jak dostat vlastní software do oficiálních repozitářů?

« kdy: 15. 05. 2023, 12:34:08 »

Lide kteri ten ten SW vyviji jsou pysni na sve vize a feedback od uzivatelu z produkce je nezajima.

Zajímá, ale musí mít nějaký hmatatelný a měřitelný přínos (nejlépe podložený daty). Oni ten kód následně musí udržovat a testovat, tak prostě nemohou přijmout cokoliv od kohokoliv.

Nicméně na sebestředné jedince samozřejmě narazíte v IT občas taky..

73

Distribuce / Re:Jak dostat vlastní software do oficiálních repozitářů?

« kdy: 15. 05. 2023, 12:31:01 »

Nemali by o tom co bude v distribucii rozhodnut skor jej pouzivatelia ako par jednotlivcov?

To se lépe řekne, než udělá. Musíte mít nějaký způsob jak toho uživatele ověřit. Takže ve Fedoře to chce účet, bug na package review a proven packager sponzora.

Na větší změny jsou volby do FESCo (Fedora steering comitee). Také existují procesy na velké změny atd, ale finálně rozhoduje FESCo. Náhodný kolemjdoucí prostě tu sílu mít nemůže, protože nemá tu zodpovědnost (ani zkušenosti).

Pro balíky mimo Fedoru je tu copr, kde si každý může uveřejnit co chce. Ale nemá to ty garance. Ubuntu myslím mělo něco podobného s repozitáři z launchpadu. Debian samotný v tomto směru neznám.

74

Distribuce / Re:Jak dostat vlastní software do oficiálních repozitářů?

« kdy: 15. 05. 2023, 12:16:59 »

- "Mas projektu adresar extlibs. Proc?, udelej separatni baliky pro kazdou knihovnu i kdyz jsou to tvoje vlastni knihovny a nikdo jiny nepouziva".
- "Mas v projektu opatchovanou verzi knohovny ANTLR". Patch resi SEGFAULT, ktery mi nehodlame opravit. Prejdi na verzi knihovny z distribuce"
- Nasli jsme v tvym projektu neco co vypada jako tabulka znaku Unicode, prejdi na knihovnu libICU.

Tohle má společného jmenovatele. Jak jste vy moc starý na tolik práce, tak oni mají dost práce i bez toho, aby museli řešit několik bundlovaných kopií dat a knihoven v případě třeba CVE. Proto všechny velké distribuce zakazují bundling. Opraví se distribuční knihovna a všechny ostatní programy jsou tím automaticky opraveny taky.

Vaše ušetřená práce by byla přidaná práce pro maintainery na roky dopředu.

Mám balíky ve Fedoře (no měl jsem), dělal jsem i maintainera v RHELu a moc dobře vím co ta údržba distribuce obnáší. Obzvláště u projektů, kterým se odmlčí autor, protože se ožení, změní práci, přejete ho auto (reálná a zažitá situace..).

Chápejte, že to ani pro ty správce není tak snadné, jak to vypadá.

75

Server / Re:Google, Seznam vs. domácí server

« kdy: 09. 03. 2023, 14:48:01 »

Ještě se dá uvažovat nad konternerizovaným řešením jako třeba mailcow: https://mailcow.email/

Dost věcí to řeší "samo".

Ale nějaká údržba a zálohování je vždy potřeba. Maily celé rodině ztratit nechcete.