Příspěvky

1

Hardware / Re:HackRF One vs Pluto+

« kdy: 16. 12. 2025, 14:16:23 »

Na seriózní RF výstup co může jít do éteru bych radši použil něco jako https://www.wideservis.cz/square-sdr-2/

Trochu jiné zaměření než HackRF One / Pluto+ jelikož to používáte jako hotovou věc, ale zase to má ty filtry a tudíž to má kultivovaný výstup.

Je pravda, že nevím, jak je na tom s výstupem HackRF One / Pluto+, ale předpokládám, že to je věc na výzkum, ne na vysílání do éteru.

2

Desktop / Re:Font rendering v různých desktopových prostředích

« kdy: 11. 12. 2025, 06:37:09 »

To bude toto issue:

https://github.com/harfbuzz/harfbuzz/issues/2394

Harfbuzz neumí spočítat správně kerning v případě, že chce uživatel horizontální hinting, takže fonty musí být rozmázlé. V xfce to funguje asi proto, protože používá staré GTK, které používá starý harfbuzz nebo jen samostatně freetype pro kerning (ale tady jen hádám, nevím přesně jestli je to tak).

Každopádně toto je problém od r. 2020 a nikdo ho řešit nehodlá.

Ale, všechno je open-source, uživatel si to může spravit přece sám.

Uff. A není aspoň nějaký workaround!?

3

Desktop / Re:Font rendering v různých desktopových prostředích

« kdy: 10. 12. 2025, 20:46:32 »

Co na tom obrázku vidím je, že Gnome uprostřed používá antialiasing jen v odstínech šedé

To by mělo jít přepnout.

[...] ale vypadá to, že KDE používá jiný kerning než XFCE a GNOME.

Na základě toho obrázku přemýšlím, jestli se tomu, co používá Xfce a GNOME dá vůbec říkat kerning...

Typograficky vypadá správně IMHO jen ten první řádek (KDE).

4

Bazar / Re:Prodám zálohy linuxových distribucí na CD a DVD

« kdy: 29. 11. 2025, 14:19:50 »

Myslet si znamená hovno vědět a "potrava pro tělo a duši" jsou takový ezokecy, který tady na hluboce technickým serveru nikdo vážně brát nebude. Jediný, co z toho je aspoň nějak podložený, je spektrální složení světla a světelná pohoda, který mají vliv na psychickej stav, ale tím to končí.
Dlouhodobá snesitelnost a udržitelnost života v bunkru je přímo závislá na jeho velikosti. Musíš mít zdroje energie (s ohledem na nutnou velikost aspoň thoriový reaktory), musíš mít populaci dostatečně velkou, aby geneticky nedegenerovala v důsledku příbuzenskýho křížení (někdo to spočítal na cca 5-30 tisíc osob), a musíš ji být schopen uživit (tzn zdroje potravy a vody) a ZABAVIT, jinak se ti tam všichni sežerou navzájem (obrazně i doslova).
Tedy dlouhodobě dává smysl bunk velikosti krajskýho města. Hodně štěstí. Živí budou závidět mrtvým.

Nálepkou ezokeců jste si moc nepomohl. A střelil jste se do vlastní nohy - psychický stav i víra přímo ovlivňuje imunitu, regenerační schopnost, kognitivní schoppnosti, schopnost komunikace, sociální koordinace a obecně vůle k přežití. K technickému materiálnímu hledisku musíte přidat pohledy z dalších oborů, což samo o sobě nemá s ezo nic společného. Je opravdu důležité, aby se člověk nezbláznil, nechytl paranoiu, byl schopen disciplíny, komunikace a podobně. Což jsou netriviální témata.

5

Vývoj / Re:Vezme AI ajťákům práci?

« kdy: 20. 11. 2025, 08:30:32 »

Podle mě může být AI dobrý jako oponent, pokud jde o na internetu masivně popsané téma. Lze s ním prodiskutovat návrh, algoritmy, struktury, ... a na základě toho si udělat sám názor. A klidně si kusy kódu nechat i vygenerovat - podle přesně popsaného zadání. Podobně se mi to osvědčilo v dalších technických oborech. Předpokladem je, že jsem schopen odlišit chybné odpovědi AI - to jest sám mám dostatečné kompetence. To je trochu v protikladu s názorem, že AI pomáhá juniorům. Podle mě pomůže spíš seniorům a pro juniory může být zavádějící. O to více bude juniory potřeba vzdělávat. Zodpovědnost nese vždy člověk.

6

Desktop / Re:Způsob sdílení obsahu mezi aplikacemi

« kdy: 14. 11. 2025, 22:50:55 »

Mě by se líbilo intenzivní použití services jako v GNUStep, tj. různé komponenty by se dokázaly registrovat do systému a v každé aplikaci by se u příslušného obsahu zobrazila nabídka služeb, které s ním umí pracovat. Podobně jako existuje nyní registrace aplikace k podporovaným mime-typům. To by bylo zobecnění těch jednoúčelových copy-paste a drag-and-drop funkcí. Služby by šly skriptovat, registrace by probíhala automaticky.

Například při označení textu bych viděl: možnost text přeložit, možnost text zkompilovat, možnost z textu vytvořit e-mail, možnost konverze velikosti písmen, možnost opravit spellcheckerem atd. Šlo by o obousměrné zpracování obsahu (převzít data anebo je převzít, modifikovat a vložit na původní místo ve zdrojové aplikaci). Celý koncept by šel ještě rozšířit na plně modulární rozhraní, kdy by bylo možné si aplikaci sestavit na míru z komponent. To už je ale složitější koncept, kdy by bylo nutné rozšířit koncept pipes u shellu na GUI prostředí a byl by nutný dobře navržený systémový event bus. Bohužel se k tomu dnes nic ani neblíží.

7

Vývoj / Re:JavaScript vs. TypeScript: rovnaký alebo rozdielny jazyk?

« kdy: 13. 11. 2025, 17:22:15 »

Stejně nechápu už tu prvotní otázku. Typescript je nadmnožina javascriptu. Nic víc, nic míň.

8

Vývoj / Re:JavaScript vs. TypeScript: rovnaký alebo rozdielny jazyk?

« kdy: 13. 11. 2025, 14:54:48 »

Ad javascript https://www.youtube.com/watch?v=et8xNAc2ic8

9

Vývoj / Re:Prečo nie je Lisp populárnejší?

« kdy: 06. 11. 2025, 23:43:30 »

Volání funkcí je v prefixové notaci. V matematice používáme i postfixovou notaci a nepřipadá nám to divné. Lisp udělal jen to, že vše sjednotil do prefixové notace, aby to bylo jednodušší.

Mno, a teď teda řekněte, proč v jazycích, které to umožňují, je taková scháňka po přeťěžování infixových oprátorů, pokud je prefix tak výhodnější.
Troufám si tvrdit, že většina programátorů radši napíše s1 + s2 + s3 nez CONCAT(s1, s2, s3), stejně tak Octonion a = b + c a ne Octonion a = ADD(b, c)

Za mě teda vítězí jednoznačně

Kód: [Vybrat]

CONCAT(s1, s2, s3)
Složité výrazy bych měl tendenci si rozepsat na více řádků a odsadit - s tím, že mi to stále přijde jako  výstižnější zápis.

10

Odkladiště / Re:Sháním nadšence do SDR z Prahy

« kdy: 25. 10. 2025, 17:35:06 »

SDR je živé téma, většina nově uváděných HAM vysílaček běží na SDR technologiích. Přes WebSDR a KiwiSDR můžete kdykoli ladit a poslouchat přes internet. SDR běžně využívají HAM operátoři na pásmech HF, UHF, VHF i dalších. Různí lidé píší demodulátory pro SDR a lze si pořídit i plně softwarově definované rádio ve kterém můžete experimentovat s vlastními modulacemi apod. Konstrukce antén je pak zas jiné nezávislé téma.

11

Vývoj / Re:AI Inference - Qwen 30b Coder - drobné chybky

« kdy: 25. 10. 2025, 11:29:42 »

Můžete použít GPU hosting a otestovat i větší modely. Např. tady si jde levně pronajmout https://vast.ai/products/gpu-cloud - platíte za propálený výkon resp. čas. takže za pár stovek otestujete i poměrně výkonné konfigurace (8x RTX 4090 48 GBVRAM $3.004/hr a desítky dalších - až po 8x B200 179 GBVRAM $24.489/hr). Ideální pro krátkodobý test, není problém si rezervovat výkon třeba na hodinu.

12

Desktop / Re:Směr práce se dvěma okny

« kdy: 14. 10. 2025, 00:13:37 »

Podle mě to není blbá otázka. Ale odpověď záleží na kontextu. U časové osy mám vlevo předešlý stav a vpravo následný stav (diff). Vlevo živý filesystém a vpravo zálohu. Taktéž vlevo lokální filesystém a remote vpravo.

Co se týče tlačítek, tak potvrzovací tlačítka vpravo dole vyjma situací, kdy má obsah proměnnou výšku, pak dává smysl mít potvrzovací tlačítka i vpravo nahoře, aby při změně obsahu neposkakovala 

13

Vývoj / Re:Přechod z Javy na Rust. Ano či ne?

« kdy: 05. 10. 2025, 22:44:07 »

Co se tyce knihoven vs vlastní kod, je tu este vykonovy aspekt.

(...)

Prototyp v pythonu funguje ok. Predelavka do go s ocekavanim narustu vykonu, realita, vykon je tretinovy.

Profilingem zjisteno, ze python je sice pomalejsi jazyk, ale ze jeho knihovny pro práci se stdio a JSON jsou mnohem rychlejsi, zrejme psane v C.

To mi přijde velmi podezřelé. Co se týče deserializace jsonu, tak tam můžou být rozdíly velké, i v rámci různých knihoven ve stejném jazyce.

(...)

Rychlost JSON serializace není moc validní kritérium pro výběr jazyka. Pro libovolný jazyk totiž vyberu dostatečně rychlou knihovnu anebo použiju binding na C, pokud je rychlost serializace skutečné úzké hrdlo. Validní kritéria jsou úplně jinde (vyspělost a vlastnosti jazyka a jeho runtime, rozšířenost, podpora, přenositelnost, kompatibilita, ekosystém, dostupnost vývojářů, ...).

14

Desktop / Re:Virtuální plocha jako nezávislé prostředí

« kdy: 01. 10. 2025, 19:44:45 »

Jde o to, co je cílem resp. motivací. Jde spustit novou desktop environment session, jde spustit novou session v okně Xnest/Xephyr, jde spustit novou grafickou session v odděleném containeru nebo lze spustit nový virtuální stroj. Přímo pomocí plochy to asi nepůjde, plocha už je součástí jediné session.

15

Vývoj / Re:Přechod z Javy na Rust. Ano či ne?

« kdy: 24. 09. 2025, 21:26:47 »

Současný UI toolkit pro javu je JavaFX.

Ono je to složitější. JavaFX je modernější než Swing a původně ho měl nahradit. Pak ale Oracle JavaFX opustil (protože si Oracle obecně s desktopovou Javou neví rady, resp. s desktopovými aplikacemi vůbec…) a nyní JavaFX stojí na nepříliš velké komunitě. Takže jeho budoucnost není moc jistá. Naproti tomu Swing je stále součástí Javy a komunita kolem něj (včetně velkých a obřích firem) je tak velká, že o jeho budoucnost není potřeba se bát.

Pro nějaký hobby projekt je JavaFX dobrá volba, pokud by ale měla vzniknout nová desktopová aplikace psaná v Javě, u které by se očekávalo dlouhodobé použití, volil bych Swing.

Typicky dnes ovládá vývojář několik jazyků a celou škálu technologií.

No, typicky dnes vývojář píše v několika jazycích. Do jaké míry je doopravdy ovládá už je různé.

Ale moc Swing nových aplikací asi nevzniká, ne? Podle mě Swing už spíš legacy framework. Javy FX by bylo škoda. Doufám, že dojde k určité renesanci desktopových aplikací.