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

Stran: [1] 2
1
Vývoj / Re:Přechod z Javy na Rust. Ano či ne?
« kdy: 23. 09. 2025, 23:08:35 »
Čo sa týka desktopových aplikácií napísaných v Jave, dlhoročne používam Netbeans a JOSM, obe fungujú bez zásadnejších problémov a nemám problém sa na ne pozerať.

2
Vývoj / Re:Přechod z Javy na Rust. Ano či ne?
« kdy: 22. 09. 2025, 23:15:49 »
Bežne prepínam medzi Javou a C, nejaké jednoduché počiny mám za sebou aj v Ruste a áno, benefity samozrejme vnímam. No predstava, že by som v ňom mal vyvíjať to, čo denne komerčne vyvíjam v Jave (s porovnateľnou efektivitou), nie je realistická. Tzn. s čiastkovými postrehmi viem súhlasiť, no celkovo sú to podľa mňa stále veľmi odlišné niky.

3
Vývoj / Re:Přechod z Javy na Rust. Ano či ne?
« kdy: 22. 09. 2025, 22:33:39 »
Je to nízkoúrovňový jazyk už len čisto nutnosťou riešiť explicitne memory management, životnosť a ownership. Čo je niečo, čo v bežnej komplexnejšej biznis aplikácii, na ktorej vývoj nie je k dispozícii celý čas sveta, človek normálne riešiť nechce.

Rovnako ako opačne, nechcem GC runtime, keď píšem regulačnú slučku pre 48 MHz Cortex-M0 s 8k SRAM alebo modul do jadra.

4
Vývoj / Re:Přechod z Javy na Rust. Ano či ne?
« kdy: 22. 09. 2025, 21:48:21 »
Moje odpověď je rust, ale hodně firem použije na server věci prostě golang
To, na čo sa dá použiť golang, nie je normálne nika pre C/C++/Rust like jazyky, to už sa dá rovnako dobre spáchať aj v Jave (s komfortom a zázemím solídneho konzervatívneho ekosystému tvoreného príčetnými ľuďmi, na rozdiel trebárs od PHP/JS bordelu) alebo inom GC jazyku s tučným runtime. Sila tamtej trojice je práve tam, kde z rôznych dôvodov nie je vhodný fat GC runtime – námatkovo napr. firmvéry, systémový sw., ovládače, meranie a regulácia, signal processing, computer vision, low latency služby a pod.

Ono celá téma vlákna je dosť bizár, prechod z Javy na Rust je niečo ako prechod z C# na C, proste úplne iné svety adresujúce iné okruhy problémov a vyžadujúce do veľkej miery aj iné zručnosti.

5
Vývoj / Re:Přechod z Javy na Rust. Ano či ne?
« kdy: 22. 09. 2025, 11:43:16 »
dnes už není moc důvod použít C++ na nový projekt - jsou mnohem lepší jazyky
Aké? Ak to je projekt, kde bol dobrý dôvod vôbec uvažovať o C++, potom reálne použiteľné alternatívy budú tak C, Rust a možno Ada. "Mnohem lepší" z toho s prižmúrením oka spĺňa možno ten Rust, aj to závisí od okolností.

6
Vývoj / Re:Přechod z Javy na Rust. Ano či ne?
« kdy: 22. 09. 2025, 05:32:40 »
golang vnímám jako zjednodušení C, escape-analýza, etc.
U Rustu nevidím nic, co by měl společného s C++. Jde úplně jinou cestou. Skoro až opačnou.

Za mňa je (z tu rozoberaných) práve jedine Rust reálne nadväzujúci na C a C++ tým, že ide cestou bez garbage collectoru. Go je alternatíva snáď tak k Jave, na typické C/C++ use cases (embedded, low resources, low/predictable latency) je problém práve to GC.

7
Bazar / Re:SSD a HDD disky k prodeji
« kdy: 12. 05. 2025, 14:08:24 »
U tých SSD je výpovednejšie skôr TBW než hodiny.

8
Hej, Linux sedí.

Windows z grubu buď cez chainloader (odovzdá riadenie MS boot loaderu, ktorý si zavedie windows) alebo ntldr (zavedie windows priamo z konkrétnej NTFS partície bez MS boot loadera; vyžaduje okrem ntldr ešte grub modul pre čítanie NTFS). V každom prípade, oba varianty vyžadujú, aby mal grub (priamo alebo cez niektorý modul) prístup k zariadeniu s tou win inštaláciou.

9
V prípade Linuxu mu stačí zaviesť binárku kernelu, ktorá štandardne leží priamo na /boot partícii spolu s grubom. Všetky ďalšie zariadenia s komplikovanejším prístupom si už obslúži ten kernel, grub samotný z nich nepotrebuje byť schopný čítať.

Bežnú inštaláciu Windowsu ale týmto spôsobom nezavedie, tam je potrebné aby mal priamo grub prístup k zariadeniu s ňou.

Čo sa týka podpory MD RAIDu, neviem ako je to dnes, no pár generácií Debianu späť som kvôli bootu grubom zakladal samostatný RAID1 na malých partíciách diskov (kde bol inak na zvyšku RAID10,f2), pretože tam bol z pohľadu čítajúceho pristupujúceho k jednému ľubovoľnému disku toho poľa layout a obsah identický s bežnou EXT3 partíciou, MD metadata boli transparentné.

10
Bez modnutia BIOSu to pôjde jedine s bootom z iného pomocného zariadenia (SATA, USB) s tým, že keď odtiaľ grub zavedie kernel s podporou NVMe, mal by už systém ďalej normálne štartovať (hoci grub samotný cez ls NVMe zariadenia neuvidí).

To sa ale týka zavedenia Linuxu (kde budú v /boot na tom biosom podporovanom zariadení priamo binárky jednotlivých kernelov), Win10 sa obávam, že takto zrejme z NVMe nezavedieš.

To čo som písal vyššie sa týka fixnutia Win10 boot cfg. v prípade použitia štandardného microsoftieho boot loaderu. Fungovať to ale bude len ak bude BIOS modnutý a bude enumerovať NVMe zariadenia a bootovať z nich (pričom v tom stave zrejme bude rovnako možné zaviesť ten windows už aj grubom, ak teda by bol cieľom dual boot).

11
Ako sa bude správať dd klon SATA inštalácie ťažko odhadovať, ja som na tie NVMe inštaloval nanovo z ISO obrazu Win10 verzie, aktuálnej v tom čase.

Ak ale potrebuješ klon existujúcej a zavádzač by nebol schopný ho z NVMe nabootovať, malo by to byť fixnuteľné cez command prompt (bootrec, bcdboot) po bootnutí z USB s ISOm, viď napr.:
https://www.wintips.org/fix-a-required-device-isnt-connected-or-cant-be-accessed-0x000000e-on-windows-10-8-8-1/

12
Čo sa týka toho bootu z NVMe, niekde sa podpora dá backportnúť modnutím UEFI BIOSu, viď napr.:

https://tachytelic.net/2021/12/dell-optiplex-7010-pcie-nvme/

(realizoval som úspešne na viacerých starších Optiplexoch)

13
Hej, z obdobných dôvodov (+ potom aj kvalita P/C schedulingu v prípade Intelov) sa prikláňam tiež skôr k AMD, akurát tá avizovaná idle spotreba je trochu odrádzajúca, starý i7 3770 je v tom veľmi decentný. Nie kvôli nákladom (50W konštantného odberu navyše robí ročne ekvivalent hodnoty tak 1-2 MH roboty), skôr mentálne, že človek páli 95% času kopu el. zbytočne, aby mal 5% času k dispozícii trochu väčší komfort. Aspoň teda na takýto lokálny dev scenár, ak by to fungovalo trebárs ako CI server, je to iná vec.

14
Zostava s CPU z výkonnejšieho konca Zen4 spektra (7900X, 7950X) 30W zrejme nie, len pre CPU pkg. ako celok sa podľa sw. monitoringu spomína okolo 20W v idle., tzn. celý setup by mohol mať odhadom tak okolo 50W (čo by som bral ešte ako akceptovateľné).

Ako oni sú relatívne efektívne čo sa týka výkonu na watt, hlavne ale pri strednej až vysokej záťaži, nie zrovna pri blízkej idle. Intely zrejme sú trochu úspornejšie pri nízkej (napriek 10nm procesu vs. 5nm pri Zen4) aj vďaka tomu, že ide o monolity, nie chiplety, kde niečo ide na vrub interconnectu.

Zdrojov čo spomínali 90+W idle pri 7900/7950X setupoch som zazrel viacero, napr. https://techgage.com/article/cpus-for-creators-amds-zen-4-vs-intels-raptor-lake/4/, preto ma zaujímajú prípadné reálne namerané hodnoty.

15
Hardware / Zen4 prípadne Raptor Lake-S: idle spotreba desktopu
« kdy: 30. 04. 2024, 08:26:28 »
Nájde sa niekto prevádzkujúci bežný "nehráčsky" systém, tzn. optimalizovaný skôr na spotrebu (bez dedikovanej grafiky, bez overclk./overvoltingu, so stock RAM profilom, atď.), napr. s R9 7900X alebo i7 14700K a vie uviesť reálne zásuvkovým wattmetrom nameranú idle spotrebu celej mašiny?

Zvažujem upgrade z letitého i7 3770 (s ktorým sa pri dostatku RAM dá stále do pohody žiť, aj na ňom vývojárčiť, rád by som ale trochu skrátil dobu premrhanú čakaním na rozsiahlejšie buildy a zbiehania testov) a po webe kolujú rôzne hrôzostrašné hodnoty (90-100W v idle pri Zen4). Je mi jasné, že to bude závislé aj od chipsetu, množstva a druhu diskov, účinnosti zdroja, OS a power mng. nastavení, atď., no aspoň pre predstavu, s akým nárastom rátať.

Stran: [1] 2