Příspěvky

1

Studium a uplatnění / Re:Prerspektivy studia IT ve světle současného vývoje AI

« kdy: Dnes v 13:19:28 »

Velkým zákazníkům jde spíše o to, aby neleaknuly jejich data, tj., aby model nezahrnul jejich otázky do svých znalostí. Některým jde o kód. Vlastně jakákoli práce s copilotama vede k leaku dat, které navíc patří firmě/zaměstnavateli, ne tomu vývojáři, co to tam dobrovolně kopíruje. A dalším jde o to, aby v obecných dotazech nebyly senzitivní informace. Třeba akciovky mají poměrně přesně zákonem dané, jak oznamují některé změny, akvizice atd. A pokud si třeba firemní copywriter nechá "připravit" tiskové prohlášení veřejným LLM, tak to už si říká o velký problém.

Ehm. Naprostá většina firem má maily v Google/MS Cloudu, soubory sdílí přes google/one drive/sharepoint, komunikuje přes Slack, Teams, Meet a Zoom - to "tiskové prohlášení" se připravuje právě tam - zdrojáky a CI mají na GitHubu a hotové aplikace pak běží v Azure, AWS a podobně (=včetně kompletních zdrojáků, pokud je to interpretovaný jazyk, a ze snadno reverzovatelných binárek (určitě tam bude verze s debug symboly) pokud náhodou není). A ty teď tvrdíš, že se situace nějak změní, když budou používat LLM často i od té stejné firmy (Gemini = Google, ChatGPT = efektivně Microsoft, Claude = AWS) hostované na té stejné infrastruktuře?

A ty extrémně paranoidní, co teď mají on-premise Azure a on-premise GitHub/GitLab prostě budou mít vedle toho další rack s GPU - on-premise LLM. Zrovna třeba DeepSeek teď dělá přesně tohle.

Tam jde, podle mě, o něco trochu jiného. S leaknutím dat se do nějaké míry počítá, úřady si je můžou i vyžádat, a proto se třeba nastavují nevypnutelná mazání soukromých zpráv na Slacku po dvou týdnech, a podobné věci. Ale když někdo z Microsoftu vynese data nějakého zákazníka, tak to bude pro MS ošklivá aféra a bude to drahé a žalovatelné, takže se ty korporáty snaží si tyhle věci navzájem nedělat. Zatímco když zaměstnanec nacpe ta samá data do ChatGPT, a za čtvrt roku to ta AI někomu vybleje slovo od slova, tak na OpenAI si ta poškozená firma nic nevezme. Může tak akorát vyhodit toho svého zaměstnance. A shareholdeři (a potenciálně úřady v případě třeba osobních dat) se začnou ptát "jak jste to mohli dovolit?" A šťourat se ve firemních procesech. Zatímco u toho emailu by se řeklo "my nic, my máme certifikaci, to oni" a problém se přehodí na ten Microsoft a tam to vyšumí do ztracena.

2

Studium a uplatnění / Re:Prerspektivy studia IT ve světle současného vývoje AI

« kdy: Dnes v 10:45:17 »

Ono se to tváří, jako že to přemýšlí, ale přitom to vůbec nemyslí. Asi jako většina lidí. Ty matematické olympiády jsou samozřejmě v trénovací sadě, takže to na ně dokáže odpovědět. Ale když přijdete na způsob, jak drobně upravit otázku tak, aby se dostala z oblasti "trénováno" do "něco nového," například použitím dostatečného počtu číslic, tak to pořád katastrofálně selže a něco si vymyslí. Viz třeba tenhle graf přesnosti.

A s lepšími modely se jen posouváme v tom grafu dál. Kdyby to skutečně umělo počítat, tak přesnost nespadne na nulu, jakmile se dostaneme z trénovací sady. Taky co jsem viděl analýzy vnitřních procesů, tak ono to sice umí napsat, jak se formálně něco dělá, ale vůbec ten proces nepoužije, dostává se k výsledku nějakými asociacemi. Trochu se s tím ty společnosti snaží něco dělat multimodálními modely a různými agenty, jako že detekovat "tohle je počítání" a místo řešení jen přechroustat pro matlab-like program, co spočítá výsledek, a ten pak zabudovat do odpovědi. Ale to má svoje problémy, dál to zvyšuje náklady, a neřeší to jádro problému. Takže dokud nepřijde nějaká změna paradigmatu v AI, současných problémů se nezbavíme.

3

Studium a uplatnění / Re:Prerspektivy studia IT ve světle současného vývoje AI

« kdy: 18. 04. 2025, 18:46:02 »

Dolovat věci tím těžším způsobem z knih a googlení v diskuzích z člověka lepšího programátora neudělá, udělá to z něj jen schopnějšího hledače. Důležité je, co pak s tou získanou informací člověk dělá dál. Můžu strávit dvě hodiny googlením a pak copy-pastnout první použitelně vypadající kus kódu ze StackOverflow. Nebo se můžu 10 minut bavit s AI a dalších 20 minut přemýšlet nad tím, co mi dala a jak to napsala. Která varianta mě naučí víc, to nechám na hodnocení ostatních. 

4

Hardware / Re:Výběr videotelefonu do rodinného domu

« kdy: 08. 04. 2025, 09:49:06 »

Jen na okraj. K cemu je dobre video na zvonku v dnesni dobe?

K tomu, abych viděl, kdo zvoní, nejen slyšel. Takže spíš naopak, pokud je potřeba řešit domovní telefon, jaký smysl má zůstat jen u hlasu?

5

Desktop / Re:Náhrada Skype pro Linux

« kdy: 08. 04. 2025, 07:12:14 »

Co Element/Matrix? Už chvíli po něm pokukuji, ale nemám moc možností tam někoho dotlačit a reálně používat, tak je to takové teoretické. Video to umí, ale netuším, jak to prakticky funguje na Linuxu.

6

Server / Re:ACME DNS Challenge problem

« kdy: 31. 03. 2025, 18:08:30 »

Pokud je ten challenge záznam opravdu jak má být, zkusil jsi prostě počkat pár hodin?

7

Distribuce / Re:Distribuce pro PC bez monitoru

« kdy: 31. 03. 2025, 16:20:41 »

Aha, tak děkuji, to jsem netušil takové omezení. Jsem asi moc dlouho windowsák, že to beru jako samozřejmost (nepřipojený monitor nedělá problém v bootu), je to obecná vlastnost všech LD nebo jen této distribuce?

Pokud vim, je to vlastnost i Windows ;-) Preci jen HDMI Dummy se opravdu nevyrabi specialne pro Linux stroje, ale obecne pro PC HW ktery ma bezet headless...

+1, měl jsem i monitor, co se na neaktivních vstupech tvářil, že neexistuje, a při zapínání Windows PC s už připojeným notebookem jsem musel vynutit hledání signálu (na DisplayPortu) přesně ve správnou chvíli, jinak ty Windows naběhly jen headless, a až do restartu tam prostě nešlo ten monitor připojit.

8

Server / Re:Jak řešíte emaily pro lidi ve firmách?

« kdy: 31. 03. 2025, 15:00:55 »

Diskový prostor je levný a 12 lidí na 10 GB je dost málo místa. Takže sice můžeš nastavit nějaká drakonická opatření a nutit lidi to mazat, ale 1) až někdo bude potřebovat smazaný email, ukáže prstem na tebe a 2) určitě někoho napadne si ty maily začít přeposílat na nějaký freemail, kde bude mít 15 GB jen sám pro sebe.

Ještě bys mohl řešit archivaci po vlastí ose, ať už jako read-only schránku, nebo nějaký webový archiv,synchronizovat
 jednou denně/týdne, best-effort stylem, a mailové schránky každý měsíc promazat. Ale asi s tím bude víc starostí, než prostě přikoupit prostor pro emaily.

9

Hardware / Re:Myš reaguje až na silnější stisk tlačítka

« kdy: 31. 03. 2025, 14:03:51 »

Tak nějaký drobeček, nebo jiný bordel pod tlačítkem, tam být může, a stisk se podaří, až když ho rozmáčkneš/tlakem ohneš myšidlo. Ale taky to může být odcházející mikrospínač. Tak jako tak, pokud ta myš nejde otevřít povolením čtyř šroubků (zásadně schovaných pod klouzavýma podložkama), ale je slepená, tak rovnou vyhodit. Pokud otevřít jde a stojí ti to za tu práci, tak nový mikrospínač vyměníš za pár (deseti)korun + pár kapek cínu. Dávat to někomu na opravu za peníze se ale zřejmě nevyplatí.

Do těch myší se dávají i u značek jako Logitech ty nejlevnější šunty, ale když je člověk s tou myší jinak spokojený a umí trochu pájet, tak nahradit ty mikrospínače za mnohem kvalitnější kusy vyjde na pár desetikorun a zbytek myši vydrží další roky, dokud neumře na rozpadající se gumoplasty rozežrané potem.

10

Software / Re:NVR software pro IP kamery a kontinuální nahrávání

« kdy: 20. 03. 2025, 14:28:48 »

Je důležité, aby byla využita HW accelerace na GPU, jinak to bude nesmyslně zatěžovat CPU.

No moj problem je prave to, ze v tom stroji nemam dedikovanu GPU asi som to mal explicitne napisat uz skor, ale predpokladal som, ze je to jasne z kontextu. Tak uz rozumiem, ze mas nizky CPU usage

Mě nepříjde, že by ta GPU musela být dedikovaná. Ať je klidně integrovaná, ale musí se používat. Ne že to bude počítat surově CPU. Pokud ti samozřejmě do toho nehází vidle Proxmox, kvůli kterému tam tu integrovanou GPU nemůžeš předat.

11

Server / Re:SSH heslo vs. klíč?

« kdy: 19. 03. 2025, 18:25:18 »

Kdyby člověk chtěl, asi nějaké důvody najde. U klíče mi zase vadí, že nejsi schopný vynutit, že klíč je šifrovaný a že se třeba nepoužívá agent, tj. nastavit nějakou policy, jediná rozumná možnost je mít HW token, kde ten klíč. To mluvím hlavně o firemním prostředí.

Tohle je asi nejzásadnější nevýhoda ověřování pomocí klíčů a je to asi taky ten hlavní důvod proč ho některé firmy nechtějí používat.

Pokud mají kontrolu nad strojem, můžou ssh-agent zablokovat. A generovat sadu klíčů na serveru a nedovolit uživatelům si nahrávat vlastní. Ale tak jako tak, co mi přesně brání si udělat ssh_company.sh, který prostě udělá něco stylem echo "username\npassword" | ssh?  To jsou ty snahy o zvýšenou bezpečnost, které vedou ke žlutým papírkům s heslem nalepeným na monitoru a pracovním čase spáleném bojem mezi IT a zaměstnanci.

12

Server / Re:HTTP/S a certifikáty v embedded zařízeních

« kdy: 18. 03. 2025, 18:45:07 »

Když nad tím přemýšlím, spuštění webového serveru na USB mi nepřijde jako až tak super koncepční řešení:

Ta IP kolize v 1. není až takový problém, pokud jde tu IPadresu změnit. Prostě podobná situace, jako u veškerého wifi IOT s AP mode pro první nastavení.

A ten zbytek... No, tam záleží, jak moc zajímavý cíl to je. Například amatérský osciloskop do USB, který má webový frontent místo instalování nějaké aplikace do systému, mi zní jako krásné využití tohohle systému. A ani úspěšný útok nemá moc co udělat jiného, než si to bricknout, nebo si v tom zařízení udělat bezpečnou enklávu pro znovu-šíření. Jasně, pokud by to ovládalo nějaké čerpadlo v rafinerii, nebo dvoutunového robota ve fabrice, tak to může udělat o dost víc škody, ale... Tak nějak pochybuju, že tam budou mít tyhlety moderní vymyšlenosti, co tady řešíme. Ovládací software dostupný jen pro WinXP je v těch kruzích pořád v módě. 

Podle situace možná stačí, když bude v prohlížečích pořád nějaká unsafe volba "považuj tenhle zdroj za důvěryhodný."

Ty nedelas nikde v administraci IT ze? Tohle nestaci uz davno.

Řešil jsem specificky situaci "funkcionalita je podmíněna použitím HTTPS," jako nějaké webgl nebo clipboard věci, a navrhl to jako self-help alternativu k pouštění lokální proxy, ne snahu držet naživu zařízení s ovládáním přes Flash. 

13

Server / Re:SSH heslo vs. klíč?

« kdy: 18. 03. 2025, 08:58:24 »

NEsouhlastím s tvrzením o populárnosti . Nesoushlastím s  tvrzením dnes. Tazatele

1) zná v plaintextu

Záleží jestli myslíš hesla obecně nebo metodu "heslo v ssh"
1)myslím, že ani heslo se neposílá mezi stranami u SSH, ale se jim(+salt) podepíše seed od serveru  (heslo se posílá snad jenom u HTTP(S) formulářů  ), ale nevim, rád se nechám poučit, jestli se ho protistrana=server dozví. Legitimní protistrana nebo i fake protistrana. Ale jisté je, že pasivní poslouchatel heslo nedokáže odsposlechnout.

https://www.rfc-editor.org/rfc/rfc4252#section-8, upozorňuji zvláště na frázi "plaintext password". Žádné solení se tam nepopisuje, ssh client prostě pošle heslo, jak ho uživatel zadal.

14

Server / Re:SSH: heslo vs kluc?

« kdy: 17. 03. 2025, 14:52:08 »

1) Heslo se posílá na vzdálený stroj, zná tvoje heslo v plaintextu. U klíče tvůj privátní klíč neopustí tvůj stroj, takže kompromitovaný vzdálený stroj by musel prolomit RSA nebo libovolnou jinou šifru, co si zvolíš.
2) Jak dlouhé je tvoje heslo? I pokud bude mít 100 znaků, bude pořád snazší ho bruteforcnout, než privátní klíč.
3) Můžeš mít jednodušší heslo pro sudo a lokální přístup, které se ti bude snadno psát, a přitom tím nekompromituješ vzdálený přístup.
4) Jestli máš víc vzdálených strojů a víc klientů, tak heslo buď máš všude stejné, nebo ho musíš řešit individuálně, řešit propagaci na klienty, a všichni klienti tím pádem znají všechno. U klíčů se prostě nakopíruje veřejný klíč, který má každý klient svůj.
5) Když to chceš mít joo secure, tak ten klíč měj s heslem, které máš v tom keepassu, a pak ani uniknutí privátního klíče ještě není okamžitě konec světa. Ale pokud ti něco sedělo ve stroji a ukradlo privátní klíč, tak ti to nejspíš udělalo i odposlech kláves, takže reálně to je stejně jedno.

15

Server / Re:HTTP/S a certifikáty v embedded zařízeních

« kdy: 16. 03. 2025, 20:29:32 »

Nevím o tom, že by prohlížeče měly v dohledné době zakázat plain HTTP. Ale jo, už dnes omezují některé technologie bez HTTPS.

Tomu trochu nerozumím - pokud se omezí technologie bez HTTPS, omezí se tedy HTTP. HTTPS-first je právě o tom

Podle situace možná stačí, když bude v prohlížečích pořád nějaká unsafe volba "považuj tenhle zdroj za důvěryhodný."
Na jeden resource v lokální domácí síti, který je běží na http, ale poskytuje nějaké https-only funkce (třeba clipboard access) to používám, akorát mi pak prohlížeč vyhazuje warning při každém spuštění, že je to zapnuté. Na druhou stranu, restartuju typicky jen jednou týdně. Ale asi to není něco, co bych chtěl učit svou tetičku, a není zaručené, že to bude takhle fungovat i za pět let.