Příspěvky

1

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

2

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.

3

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

4

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.

5

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.

6

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.

7

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.

8

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.

9

Hardware / Re:Doplnění ECC RAM do stávající sestavy HP Z440

« kdy: 10. 08. 2025, 17:55:49 »

Otázka je, jak zásadní je výkon:

1. Nejjednodušší je mít přesně stejné modely.
2. Když už to nejsou stejné modely, je dobré mít stejné parametry. Zejména frekvenci a tři čísla u časování (CL). Pokud se parametry liší, jede se podle slabší RAM. Takže přidat slabší RAM znamená zpomalit ostatní, přidat silnější RAM nemá význam.
3. Když už parametry nejsou stejné, je fajn, když aspoň nejsou horší. Trošku tricky to je u různých frekvencí – se snížením frekvence se změní i časování, zhruba nepřímo úměrně. Ideální je si to vyčíst třeba z dokumentace. Důvod je, že to časování se uvádí v počtu taktů, takže při nižší frekvenci stejný čas uplyne za méně taktů.
4. Když se swapuje, i neoptimální kombinace může být lepší než nic. Já si nějakou neoptimální kombinaci vyzkoušel dočasně kvůli reklamaci, a holt pomalejší RAM byla mnohem menší zlo než swap.

10

Software / Re:Stažené soubory s nesedícím md5

« kdy: 06. 08. 2025, 09:50:44 »

Pokud si tu knihovnu stáhne v binární podobě bez další kontroly, a autor té knihovny (nebo někdo po cestě, třeba CI) se snaží udělat útok, je to problém i s řádnou kontrolou hashů.

Pokud si tu knihovnu kompiluje NextCloud nebo pokud má reproducible build, je zase těžší tam něco smysluplného podstrčit, aniž by to ve zdrojových kódech vypadalo divně. Upravit zdrojový kód tak, aby z kompilátoru vypadla zvolená sekvence dat (pro útočníka v podstatě náhodný blob) na vhodné pozici, není úplně sranda. Nejlépe by to šlo asi nějakým stringem, ale pak nemusí být úplně sranda jeho přítomnost nějak rozumně obhájit. Proto mi obrázky a další data přijdou pro útočníka příhodnější.

11

Software / Re:Stažené soubory s nesedícím md5

« kdy: 06. 08. 2025, 08:44:00 »

A k pre-image útokům na MD5 jsem našel pár let starou informaci, že jsou zatím prakticky neproveditelné, nejlepší známá možnost je vlastně méně než 25* méně složitá než hrubá síla: https://security.stackexchange.com/a/261417

Reálné útoky se tedy spíš soustředí na to, aby nebylo potřeba najít jiný pre-image, ale jen obyčejnou kolizi. Nevím, jestli je k tomu prakticky použitelná samotná knihovna třetí strany, spíše nějaká binární data jako třeba obrázek. Nebo něco, kam lze skrýt vhodná metadata, aniž by to bylo někomu divné.

12

Software / Re:Stažené soubory s nesedícím md5

« kdy: 06. 08. 2025, 08:21:35 »

Podstatnym kvalitativnim ukazatelem dobreho hashe je, ze i pri zmene byt jednoho bitu, bude cely hash vypada uplne jinak Takze nezalezi na delce.. zmena bude patrna uz z prvnich (ci poslednich) cislic. (ostatne to je princip i zkracovani u git commit hashe)

Bavíme se o náhodné kolizi prvních/posledních pár bytů, nebo o cílené kolizi? Cílenou kolizi pár bytů uděláte hrubou silou. U sedmimístného git commit id máte 4*7 = 28 bitů, to je s brute force hračka, to spočítáte dnes snad i na hodinkách. Pokud můžete měnit něco na konci souboru, dokonce ani nemusíte pokaždé počítat hash od začátku, ale můžete podstatnou část výpočtu sdílet.

BTW, kdysi dávno (tak před 20 lety) jsem narazil na ffp (fuzzy fingerprints), což je nástroj, který generuje klíče, jejichž hashe vypadají vizuálně podobně: https://www.usenix.org/system/files/login/articles/105484-Gutmann.pdf

13

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

« kdy: 26. 07. 2025, 22:09:25 »

Kit: Jenže tady mi přijde, že se od „Nepitřebuju framework“ dostáváme k „Vytvářím vlastní framework, protože existující mi nevyhovují.“. Nechám stranou výhodu vašeho/tvého přístupu oproti jiným frameworkům (to by tu už bylo asi hodně OT), podstatné je, že tomu bych pak neřekl vývoj bez frameworku.

BoneFlute: Tak ony budou existovat věci, kde framework smysl fakt nedává. Dělal jsem třeba skript, který podle nějakých kritérií řadí řádky na vstupu. Něco jako /usr/bin/sort, ale s jinými kritérii řazení. Nečte to nic z cmdline, jen ze stdin řádek po řádku. Framework by tu asi ničemu nepomohl.

Na druhou stranu, hranice, kdy se nějaký vhodný framework vyplatí, může být i docela nízko.

14

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

« kdy: 26. 07. 2025, 12:24:47 »

No PHP toho má spoustu v základní výbavě. Ale pokud se něco nezměnilo, i u jednoduchých aplikací se framework hodí:

1. Jednoduchý formulář funkční bez JS, s validací. Když data nejsou validní, zobrazit formulář i s daty. Kontrolovat, jestli skutečně dostávám string, nebo třeba pole. Možná ještě řešit CSRF. Prostě takové základní věci. Bez frameworku to je opruz a náchylné na chybu.
2. OK, dnes bychom mohli akceptovat, že potřebujeme JS, a bez něj formulář fungovat nebude. Poslat můžeme třeba i JSON, vrátit můžeme též JSON. Opět ale validace dat (a případně řešení CSRF) je bez nějaké aspoň jednoduché knihovny opruz.

15

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

« kdy: 22. 07. 2025, 11:40:59 »

Priority mohou být různé, například:

1. Co nejrychlejší start.
2. Co nejmenší velikost binárky
3. Co nejdříve mít prototyp, na základě kterého se rozhodne, zda bude další vývoj, a kam se má ubírat.

V prvních dvou případech se může hodit (zejména u jednoduchých věcí) framework nepoužít vůbec, případně použít něco fakt malého. Třeba i za cenu složitějšího vývoje a zevrubnější kontroly, že jsem nezapomněl na nic z toho, co by za mě mohl řešit framework. Asi jde o celkem specifické případy, ale nastat mohou.

Ve třetím případě se naopak nejspíš vyplatí to udělat jakkoli, možná použít nějaký framework bez pečlivého výběru, prototyp nějak narychlo naprasit, a až bude zpětná vazba, třeba to celé zahodit a udělat od nuly s většími znalostmi. Jasně, není to platné za všech okolností, ale někdy to může být (i s ohledem na dostupné informace) ideální postup.