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

Stran: [1] 2 3 ... 13
1
Hardware / Re:Hardware s nízkou spotřebou pro domácí lab
« kdy: 01. 12. 2025, 13:30:17 »
U vyšších řad AMD dělá spotřebu infinity fabric (interconnect) mezi více CCX. Takže Ryzen 9950X bude v idle žrát víc než slabší 8 core Ryzen, jen kvůli IF.

Takže pro sestavy co mají mít super spotřebu bych volil CPU co má 8 jader a míň.

Pokud se jedná o desktop CPU tak určitě AMD - AMD má AVX-512.

2
Bazar / Re:Věnuji RPi 5 16GB na opravu
« kdy: 28. 11. 2025, 12:33:56 »
Nechápu tyto směšné argumenty proti EU, prostě máš zmetek no, to se stává, a olovo na to nemá vliv.


3
Hardware / Re:Výběr herního PC pro děti do 30 000 Kč
« kdy: 25. 11. 2025, 09:29:35 »
Já bych se třeba podíval na bazar, jestli bych tam našel něco zajímavého, a za ušetřené peníze (oproti novému) bych buď dokoupil RAM a nebo to vylepšil (lepší CPU, GPU, zdroj, bedna, podle potřeby).

4
Bazar / Re:Prodám monitor 43" 3840×1200 100 Hz
« kdy: 16. 11. 2025, 23:19:02 »
Mě to udělal nějaký asi 3 roky starý LG panel (43"). V noci to vypadalo trochu jako noční obloha (vadné pixely jako hvězdičky).

5
Bazar / Re:Prodám monitor 43" 3840×1200 100 Hz
« kdy: 16. 11. 2025, 14:24:22 »
Přesně tak - podle mě koupit si 4 roky starý monitor za 10 litrů může jen blázen. Já měl 3 monitory za posledních 5 let (mám 2 na stole) a některé odchází celkem rychle (třeba IPS panel už nechci, protože počet dead subpixelů hodně roste se stářím toho panelu).

Ale pokud to prodals za těch 10 litrů, tak gratulace, já bych něco takového prodával tak za 4-5k.

6
Windows a jiné systémy / Re:Vlastnosti macOS pro linuxáka
« kdy: 07. 11. 2025, 15:23:06 »
Binding kláves je opravdu hell, a ono to ani nejde na macu udělat tak, jak to je v Linuxu. Na toto si člověk buď zvykne, nebo ne, já jsem si na to moc nezvyknul a nejlíp se mi dělá stejně v Linuxu, ale mac používám denně.

7
Studium a uplatnění / Re:Je programátorů moc, nebo málo?
« kdy: 31. 10. 2025, 19:13:16 »
Jo, AI umí dramaticky akcelerovat práci prvních pár měsíců, ale juniory programovat nenaučí.

Pokud člověk vidí programování jako chatování s AI, tak stejně brzy skončí.

Podle mě je AI dobré pro seniory, kteří dokážou rozeznat bullshit od dobrého kódu. Junior to ale většinou nedokáže, takže AI asistent je některé věci učí blbě.

Podle mě se člověk prostě musí naučit věci časem - to je jako kdybych chtěl po dětech, ať se s AI naučí za 1 rok všechno co ve škole dělají 9. Prostě to nejde.

8
Studium a uplatnění / Re:Je programátorů moc, nebo málo?
« kdy: 29. 10. 2025, 14:23:08 »
Programátorů je obecně málo, hlavně těch dobrých.

AI neumí programovat, AI umí automatizovat. Takže s AI programátor udělá víc, ale moc is "neodpočine". To je jak v supermarketu ty self pokladny. Jedna pokladní jich může obsluhovat třeba 15, takže všechno jde rychlej, protože to je semi-automatizované, ale ten člověk co tam pracuje se z toho za chvilku zblázní :)

Podle mě AI ohrožuje hlavně juniory a to ve 2 věcech: Pokud si to člověk neodpracuje tak z něho senior nebude (a práce s AI není moc programování) no a pokud firmy nebudou chtít zaměstnat kvůli tomu juniory, tak v budoucnu zase budou chybět senioři.

No a teď tu někdo mluví o open-source. Ten trpí tím, že lidi obecně nechcou pracovat zadarmo, a když jo, tak mají vlastní věci, na kterých je pracovat baví. Většina open-source co známe má placené vývojáře, jak z různých firem, tak placené kdejakýma foundations.

9
Vývoj / Re:Přechod z Javy na Rust. Ano či ne?
« kdy: 01. 10. 2025, 23:44:39 »
Já jen použil příklad co tu byl, kdybych měl vytvořit vlastní tak by zněl takto:

```
struct Point {
  double x, y;
};
```

Chci vůbec mít member funkce? Já třeba preferuju `distance(p1, p2)` než `p1.distance(p2)`. To samé když vidím třeba `a.dot(b)`, atd... přijde mi to až přehnané API navrhovat takto.

10
Vývoj / Re:Přechod z Javy na Rust. Ano či ne?
« kdy: 01. 10. 2025, 14:39:08 »
Kód: [Vybrat]
vaha.zvazit(osoba)
osoba.zvazitSe(vaha)

Oboji je spatne. Melo by to byt akce::zvazit(osoba, vaha) - a je to. Osoba nemusi znat nic o vaze, a vaha muze umet vazit treba i zvirata nebo mouku.

Cele OOP je do jiste miry divne, nuti nas vazat akce na konkretni objekty, ktere by klidne mohly byt naprosto nezavisle.

11
Vývoj / Re:Přechod z Javy na Rust. Ano či ne?
« kdy: 26. 09. 2025, 11:35:16 »
Napsat si něco sám má své výhody i nevýhody. Výhodou je, že nad tím mám plnou kontrolu - dodržuji zpětnou kompatibilitu, když to potřebuji, nedávám tam funkcionalitu, co nepotřebuji. Nevýhodou je, že stojí čas si to napsat. Občas to je však méně času, než se naučit používat cizí knihovnu, nebo tu cizí knihovnu ohnout, aby fungovala, jak potřebuji.
Ještě jsi zapomněl na jednu další nevýhodu - zavedeš si tam bugy. Žádný kód nejde napsat bez bugů, a na rozdíl od cizí knihovny ti je nikdo neopraví. Všechny je musíš najít a opravit sám (ano, pokud by ta cizí knihovna byla nekvalitní, tak v ní nejspíš bude víc bugů než ve tvojí implementaci, ale u kvalitní, zavedené a "battle-tested" knihovny to až tolik nehrozí).
Knihovny mají tendenci být komplexní a řešit věci, z nichž většinu pro svůj úkol nepotřebuji, a jediná funkce té pro mě nepotřebné části je, že je akorát potenciálním zdrojem chyb a exploitů. Vždycky je dobré zvážit, zda se vyplatí nějakou prkotinu na pár řádků řešit knihovnou čítající desítky-stovky tisíc LOC, z nichž každý má nějakou nenulovou pravděpodobnost, že je zabugovaný. Nehledě na to, že je nelidské, když třeba mobilní aplikace na pouhé posílání zpráv zabere víc, než byla kapacita mého prvního hard disku na PC.

Já kvůli jedné funkci radši použiju knihovnu fmt, než abych si to psal sám. Je to battle-tested knihovna, kterou už někdo napsal a pořádně otestoval, a jako bonus na ní pořád někdo pracuje a dělá ji rychlejší.

Toto byl jen příklad, který vyvrací to tvrzení o jedné funkci.

Já taky nepotřebuju knihovnu na to, abych zaokrouhlil floating point half way up třeba, ale nechci si psát fmt nebo nějaký high performance logging, atd...

12
Vývoj / Re:Přechod z Javy na Rust. Ano či ne?
« kdy: 25. 09. 2025, 14:21:30 »
Já si ale nechci psát vlastní asio, fmt, spdlog, JSON parser, XML parser, YML parser, algebru, OpenCV, ... Nedělal bych nic jiného než si jen psal to co už je 1000x hotové. Pokud si člověk vybere knihovny, které jsou battle tested, tak s tím přece není problém.

Jen super jednoduché projekty nic nepotřebujou.

13
Vývoj / Re:Přechod z Javy na Rust. Ano či ne?
« kdy: 25. 09. 2025, 12:52:11 »
To, že něčemu důvěřuješ je sice hezké, ale to ještě neznamená, že tam nejsou kritické chyby. Ty se vždycky objeví i u těch nejdůležitějších projektů. Důležité je mít o tom všem přehled, a ten prostě nemáš, když si děláš všechno sám.

Mít minimum závislostí v C++ projektu není žádný benefit - je to důsledek toho, že C++ nemá package management tak jako ostatní jazyky. Header-only knihovny taky vznikly jen z toho důvodu, aby nikdo nemusel řešit kompilaci těch knihoven, a malé knihovny co řeší jen velmi konkrétní problém v C++ skoro neexistujou a nebo je nikdo nepoužívá kvůli tomu, aby neměl další závislost, o kterou se musí "manuálně" starat.

Mít package management je automatizace, nemít ho znamená dělat všechno ručně... Je to čistá ztráta času vývojáře.

14
Vývoj / Re:Přechod z Javy na Rust. Ano či ne?
« kdy: 24. 09. 2025, 22:13:22 »
Objektivně ale když nepoužiješ cargo, tak naopak ztrácíš spoustu informací které k tomu auditu potřebuješ.

Myslím si, že cargo (nebo i třeba npm či nuget) je mezivrstva, která dělá těžší detekovat backdoory nebo jiný prapodivný kód. Problém je, že v crates repozitáři občas bývá jiný kód než v repozitářích se zdrojovými kódy.

Dokonce studie z minulého roku zjistila více než 15 procent z nejpoužívanějších 999 crate mají na crates jiný kód než v repozitářích. Takže mi to přijde jako časovaná bomba.

Osobně si naklonuji repozitář, projdu si jednotlivé commity a pak si vyberu určitý commit, který vložím do svého projektu. Nebo používám přímo API operačního systému či široce používaných knihoven, kterým věřím víc než nějakým frameworkům.

Jenže dobrý package management znamená, že lidi začnou publikovat menší knihovny, které řeší jednu konkrétní věc. Hledat commit, který ty chceš, když máš N závislostí, a ty závislosti můžou mít tranzitivní závislosti je jen obrovská ztráta času.

Package management řeší totiž i ty tranzitivní závislosti, a popřípadě konflikt mezi něma. Pokud používám ekosystém, kde jsou knihovny na jednu věc, a ne frameworky co mají tunu funkcí, tak tento přístup prostě není možný.

Co je horší, v C++ začal být trend "header-only" knihoven, které lidi dropnou do projektu a už nikdy neaktualizujou. Toto je naprosto katastrofické, protože je ani nezajímá jestli tam třeba není nějaká chyba.

Package management právě řeší dobře ty chyby v závislostech. Nebo chceš mi říct, že když aktualizuješ tvoje závislosti, tak děláš review každého commitu co ty závislosti mají? Tomu nevěřím, že by to bylo možné dělat i u menšího projektu.

Už se mi moc nechce o tom diskutovat. Jen bych doplňil ještě pár věcí o C++:

  - ještě jsem nikdy nezažil C++ projekt, kde by přišli vývojáři a začali hned pracovat - místo toho se začnou hádat o coding style, kde použít exceptions, kde používat result/expected typy, atd... C++ má milion konvencí, co lidi tak nějak používají jednou tu a jednou tam, ale dohodnout se je velmi těžké. I nastavit věci jako automatické formátování atd...

  - když jsem začínal v minulosti C++ projekty, tak nastavit build system a CI, aby tam byly různé sanitizery, testy, podpora pro různé platformy, gtest, SIMD, atd... To je práce na týden a vždycky to dopadlo tak, že jsem vzal jiný projekt a udělal copy/paste základního CMakeLists.txt a CI pipeline, a jen upravil pro potřeby nového projektu. Prostě nastavit C++ projekt je neuvěřitelný opruz a CMake ačkoliv používaný v C++ ekosystému, je ten největší hnus co jsem kdy musel používat.

15
Vývoj / Re:Přechod z Javy na Rust. Ano či ne?
« kdy: 24. 09. 2025, 18:23:31 »
Jo ten audit C++ závislostí bych chtěl taky vidět, to nejde udělat, pokud ty závislosti mají miliony řádků unsafe kódu...

Stran: [1] 2 3 ... 13