Příspěvky

1

Vývoj / Re:Rozdíl mezi ASM a strojovým kódem

« kdy: 13. 03. 2026, 08:08:58 »

Případně přenositelnost, kdy stejná instrukce na jiném procesoru má jiný kod.

Teoreticky ano, prakticky o tom silně pochybuju, nebo by muselo jít o dost omezený kousek kódu.

Nemá moc smysl dělat procesor se stejnou instrukční sadou, ale jinými opcodes. Když už stejná instrukční sada, tak lze docela čekat i stejné opcodes.

A když bude instrukční sada jiná, čekám, že u netriviálního kódu bude příliš odlišná na to, aby šlo napsat stejný assembly code a jen to přeložit jiným assemblerem.

Pokud oba procesory budou mít aspoň podobnou základní koncepci, možná to půjde u nějakého triviálního kódu. Hádám, že to typicky nebude kód, u kterého bude dobrý důvod použít asm. Tady se spíš v praxi uplatní relativně vyšší jazyk (C/Rust/Fortran/…) a dnes celkem dobře zvládnuté optimalizace v kompilátoru.

EDIT: Možná je realističtější opačný scénář: máme dvě rodiny CPU se stejnou (či dostatečně podobnou) instrukční sadou, ale budeme v asm mít dvě různé verze kódu. Sice obě budou fungovat na obou CPU, ale dvě různé verze budeme mít kvůli výkonu.

2

Desktop / Re:Ovládání počítače pouze z klávesnice

« kdy: 31. 01. 2026, 10:13:15 »

Z klávesnice toho mohu udělat spoustu, ale spíš to beru podle toho, co je po ruce.

Prostředí mám i3 (pro Wayland: Sway). Tady lze měnit i třeba velikost dlaždic klávesnicí.

3

Hardware / Re:Počítač se nezapne se zařízeními v USB

« kdy: 17. 01. 2026, 11:53:13 »

Takhle to v reálu úplně nefunguje. Některé porty USB A v PC i NTB (na většině mých PC a NTBs se kterými dělám) jsou napájené i když je zařízení samotné vypnuté, může se to lišit jestli je zařízení zapojené v el. síti nebo ne. Je to (podle mě) z důvodu, aby šlo probudit PC/NTB třeba externí usb klávesnicí.  Tohle bývá možné v biosu zapnout/vypnout.   - To by také mohla být jedna z věcí co by tazatelce mohly pomoct.

To IMHO není nijak v rozporu s tím, co jsem napsal. USB A samice prostě může (a měla by, pokud je aktivní) připojenému zařízení poskytovat napětí. Nepsal jsem nic o tom, že by neměla, pokud je počítač vypnutý.

Akorát jsem si tam všiml jedné zavádějící formulace:

* Naopak u velkého USB A poskytuje napájení hned a klasický velký USB A* port by ani neměl být napájen.

Tím „by ani neměl být napájen“ jsem myslel, že by samice neměla dostávat napájení od samce. Nikdy. Ani při vypnutém počítači, ani při zapnutém.

4

Hardware / Re:Nový mobil: OnePlus 13 vs. 15 vs. Pixel 10 Pro

« kdy: 17. 01. 2026, 09:16:31 »

Bez upřesnění požadavků může být nejlepší kterýkoli z nich. Anebo třeba tlačítkový Aligator. Těžko říct bez křišťálové koule.

Pro Pixel hrají pravidelné bezpečnostní updaty, nevím, jak je na tom OnePlus. A pro někoho může být i výhoda podpora například GrapheneOS, jak bylo zmíněno. Ale opět – bez požadavků těžko doporučovat.

5

Hardware / Re:Smart zásuvka a věci okolo inteligentní instalace

« kdy: 17. 01. 2026, 09:01:39 »

Ad Matter – bacha, je potřeba rozlišovat Matter over Thread a Matter over Wi-Fi. Obojí může být použitelné, ale má to jiné požadavky na infrastrukturu. A v případě používání Threadu bych dal přednost zásuvce na Threadu, může se zapojit do meshe. Další důvod může být snadnost odříznutí od Internetu. V případě Wi-Fi to nejspíš znamená vhodně nakonfigurovat router (pokud to zvládne), v případě Threadu vlastně nevím. Chci se mrknout na konfiguraci Thread border routeru.

Ad automaticace přímo na zařízení – pokud lze zásuvku flashnout, lze něco vyřešit i v ESPHome, je-li podporovaná.

Ad ovládání na dálku – to může znamenat leccos, ne vždy je potřeba cloud:

a. Dálkové ovládání v rámci bytu.
b. Automatizace v rámci bytu – čidlo pohybu, teploměr, vlhkoměr, měření příkonu/proudu, časovače…
c. Ovládání odkudkoli po světě, kde je k dispozici Internet.

V prvních dvou případech to jde v pohodě bez cloudu.

6

Hardware / Re:Počítač se nezapne se zařízeními v USB

« kdy: 12. 01. 2026, 08:16:08 »

Ad napájení přes USB C:

* Pojem USB C OTG mi nedává smysl. OTG přepíná mezi USB A a USB B.
* Samice by neměla být napájená, dokud si o to neřekne protistrana, samec může a nemusí. Souvisí to s kompatibilitou s USB A/B a řeší to propojení dvou zdrojů kabelem. USB C musí počítat s tím, že druhá strana bude chtít být napájena, i s tím, že bude chtít napájet.
* Naopak u velkého USB A poskytuje napájení hned a klasický velký USB A* port by ani neměl být napájen.

Jsou tam zařízení připojena do USB A, nebo do USB C?

*) IIRC existuje mini/micro A, a některý z nich má i podporu OTG, tam situace může být jiná. Ale tyto konektory jsem viděl jen na obrázku.

7

Vývoj / Re:FP a error handling

« kdy: 05. 12. 2025, 09:12:14 »

V ryzím FP nemá chytání výjimek svoje místo. Házení výjimek problém není – každý výraz se může buď vyhodnotit, nebo jeho vyhodnocení může selhat (např. skončit nekonečnou sérií tail callů – každý Turing-complete jazyk musí něco podobného umožnit), a výjimky jsou jen jiným druhem selhání. A kde o užitečnější druh selhání než nikdy nekončící výpočet. Ale chytání výjimek je teoreticky problematické – když se nějaký podvýraz není schopen vyhodnotit, najednou to může způsobit úplně jiný výsledek.

V reálných jazycích bývá typicky snaha o nějaký pragmatický přístup k FP, ne o ryzí FP. Jo, je to rozdíl mezi Haskellem a F#. A jak bylo zmíněno, F# má fungovat na platformě .NET s dalšími jazyky, a tyto jazyky mohou házet výjimky, takže F# je umí házet a nejspíš i chytat.

Disclaimer: F# jsem viděl jen z rychlíku (s Haskellem jsem na tom lépe), nicméně ten dotaz je celkem obecný, tak jsem si na něj troufl odpovědět.

8

Hardware / Re:PC sestava pro Linux

« kdy: 07. 11. 2025, 15:45:54 »

OK, někdy to půjde takto na jeden krok. Horší by to bylo v situaci, kdy bych chtěl celé VM dát všechna jádra, ale pak pinovat konkrétní vCPU. Tam už to bude dvoukrokové.

9

Hardware / Re:PC sestava pro Linux

« kdy: 07. 11. 2025, 14:04:48 »

Hmm, no, s virtualizací (Xen) nevím, jestli bych chtěl řešit afinitu k jádru. Tam mám o vrstvu víc.

10

Hardware / Re:PC sestava pro Linux

« kdy: 07. 11. 2025, 10:14:46 »

Z hlavy nevím, ale minimálně u starší generace (Zen 3) znamenalo X3D pro mé použití horší výsledek za více peněz. A zvlášť pokud bych to srovnával s modelem ve stejné cenové hladině (tzn. vyšší model, ale bez X3D), rozdíl už může být značný.

Kolik s tím strávit času – otázka preferencí. Dneska bych asi sestavu naházel do Perplexity, popsal svoje použití a požadavky, zapnul režim Labs, a dostal bych nějaký feedback i se zdroji. Nebude to dokonalé a nevěřil bych tomu bezmezně, ale na poměr cena (tzn. strávený čas) / výkon (tzn. dobrý výběr) to může být celkem dobré.

11

Hardware / Re:Chování nabídky napětí USB-C nabíječky s PD

« kdy: 07. 11. 2025, 09:56:50 »

Jo, tam ty diody na usměrnění asi musí být. (Viděl jsem teda step-down, který byl ochoten pustit proud v opačném směru, ale to bylo DC-DC. I když, u powerbank je pak otázka, jak se s tím poperou…) Jako je to šedá zóna, se kterou si spousta elektroniky poradí. Ale ve specifikaci je asi dobrý důvod myslet i na to, že by si s tím v principu nějaká elektronika poradit nemusela (autoři specifikace nemohou znát veškeré existující implementace…). Jo, kdybychom měli rovnou USB C bez kompatibility s USB A/B, možná by dávalo smysl to navrhnout jinak, a po každém zdroji požadovat, ať se se situací vyrovná. V době USB A/B to těžko mohl někdo tušit.

12

Hardware / Re:PC sestava pro Linux

« kdy: 07. 11. 2025, 03:42:16 »

Kdysi platilo, že X3D jsou lepší pro hry, ale horší pro kompilaci.

13

Hardware / Re:Chování nabídky napětí USB-C nabíječky s PD

« kdy: 07. 11. 2025, 03:31:49 »

Nevím, jestli proti spojení dvou zdrojů bude chránit dioda, záleží na implementaci. Každopádně:

1. Dioda znamená nějaký pokles napětí (=> ztráty a teplo), navíc se může lišit s proudem. Obojí je problematické.
2. Jedním z těch zdrojů může být i USB A, kde se s tím ještě spíš nepočítalo. Ale pravda, USB C zdroj by s tím měl počítat, pokud na druhé straně bude USB A, tak to nebude čekat na povolení. Ale právě proto USB C samice nesmí jen tak napájet bez souhlasu protistrany.
3. Vzpomínám si na tabulku s USB huby pro Raspberry Pi první generace, IIRC jich svého času dost umožňovalo backfeeding, kdy se celé Raspberry Pi napájelo z hubu přes USB A na Raspberry Pi, ačkoli tento konektor má přenášet proud výhradně opačným směrem.

14

Hardware / Re:Chování nabídky napětí USB-C nabíječky s PD

« kdy: 04. 11. 2025, 08:01:56 »

S nabíječkama z IKEA za pár stovek tu asi budu vypadat trošku posh, ale oproti těm z Alíku mám větší důvěru, že nevyhořím, i že budou fungovat.

Ad 5V v USB C – upřesním: Je naprosto OK, že těch 5V bude na samci, který není k ničemu připojen. (To je běžná situace u USB A-C kabelů.) Ale toto napětí nesmí být na samici, dokud si to protistrana nevyjedná. Důvod je jednoduchý – představte si propojení dvou USB C zdrojů kabelem, případně totéž u USB A a USB C zdroje. Pokud na USB C samici bude 5V (±5%), pak se oba zdroje propojí. Ne vždy to bude problém, ale může tu být rozdíl až 0.5V, pak silnější zdroj bude zkoušet krmit ten slabší.

Krmit z USB něco bez vyjednání proudu je problém, zvlášť pokud jsme nad 5V 0.1A. Zdroj může omezit proud a koncové zařízení by to mělo respektovat.

15

Vývoj / Re:Framework vs. čistý kód

« kdy: 17. 08. 2025, 15:23:11 »

Pokud framework vnucuje styl chybně, jde o chybně vybraný framework.