Příspěvky

1

Vývoj / Re:Nový systém pro vývoj softwaru

« kdy: 09. 06. 2026, 09:58:42 »

... a když to vezmu kolem a kolem... tak bych šel ještě hlouběji - na co HTML na texty? na co texty? bude AI - kdo by měl číst? a programovat? proč? na co? zdlouhavý - něco psát a číst... AI si s náma popovídá nově narození nebudou chtít číst a psát když bude AI vše povídat...

Třeba na komunikaci s tou AI? Co koukám, tak +- všechny AI mají primárně textové rozhraní. Nějaké povídání se řeší akorát tak další konverzní vrstvou.

To textové rozhraní je úspornější, rychlejší a zároveň míň náchylné na okolní prostředí.
Hlas má výhodu hlavně když tu komunikaci dělám bokem k něčemu dalšímu, takže nemám volné ruce. Prostě z nějakého důvodu nemůžu použít pořádnou klávesnici.

Proč by měl ve dnešní době někdo ztrácet čas posloucháním nějakého povídání, když to může prohnat skrz AI a dostat to důležité a zajímavé jádro v pár řádcích textu?

2

Vývoj / Re:Nový systém pro vývoj softwaru

« kdy: 03. 06. 2026, 08:59:44 »

To není, vymáčknout ze současných LLM funkční strojový kód hraničí s nemožností. Ale to je dáno v první řadě chybějícími trénovacími daty.

Zajímavé. Pro každý kousek zdrojáku v současných trénovacích datech můžeme jednoduše dostat několik odpovídajících kousků binárky. A to ještě jednodušeji než shánění současných trénovacích dat.

Já bych řekl, že to není v trénovacích datech záměrně. "lnk" to popsal dobře. Poslední co chceme je chroustat hory dat, které jsou informačně extrémně řídké a osekané. Klíčová informace ve zdrojácích jsou identifikátory a ty jsou takřka kompletně pryč.

Dekompilace a úpravy strojáku je extrémně náročná věc a má cenu ji dělat jen když není jiná možnost. A je úplně jedno, jestli to bude dělat AI nebo člověk. Ty potřebné skilly vezmou hromady zdrojů, které budou chybět jinde.

Moje reakce byla na nápad vymýšlet další zbytečný jazyk speciálně přizpůsobený LLM/AI, který by ani nemusel být čitelný pro člověka. Závěr, který si z toho měl čtenář udělat, je, že by to bylo zbytečné.

A proč by to bylo zbytečné? To jste jaksi nenapsal.

Akorát jste něco plácl a pak upřesnil i to, že sám víte že to takhle nejde.

3

Vývoj / Re:Nový systém pro vývoj softwaru

« kdy: 03. 06. 2026, 07:43:11 »

To není, vymáčknout ze současných LLM funkční strojový kód hraničí s nemožností. Ale to je dáno v první řadě chybějícími trénovacími daty.

Zajímavé. Pro každý kousek zdrojáku v současných trénovacích datech můžeme jednoduše dostat několik odpovídajících kousků binárky. A to ještě jednodušeji než shánění současných trénovacích dat.

Já bych řekl, že to není v trénovacích datech záměrně. "lnk" to popsal dobře. Poslední co chceme je chroustat hory dat, které jsou informačně extrémně řídké a osekané. Klíčová informace ve zdrojácích jsou identifikátory a ty jsou takřka kompletně pryč.

Dekompilace a úpravy strojáku je extrémně náročná věc a má cenu ji dělat jen když není jiná možnost. A je úplně jedno, jestli to bude dělat AI nebo člověk. Ty potřebné skilly vezmou hromady zdrojů, které budou chybět jinde.

4

Vývoj / Re:Nový systém pro vývoj softwaru

« kdy: 18. 05. 2026, 07:29:25 »

Pracuji na tom již pár let a zde na fóru jsem se ptal jen dílčí otázky. Teď můj cíl však zveřejňuji k širší diskusi, neboť ho směřuji především na vývoj aplikací a dalšího softwaru.

Moje otázka zní: Co byste chtěli vylepšit na stávajících platformách určených především k vývoji?

Po pár letech práce se na fórum přijdete zeptat, jaký přesně problém by bylo třeba řešit?

Má to být totální revoluce (photoshop za 5/4 člověkoroku) nebo evoluce (vylepšení stávajících platforem)?

Používat by to měl kdokoliv, kdo by chtěl něco vyvinout. Tedy jak profesionálové, tak lidi, co to mají jako hobby.

Takže pro úplně všechny a na úplně všechno?

Že by na mě te projekt působil nadějně opravdu nemůžu říct.

5

Studium a uplatnění / Re:Kam odejít z IT v době AI?

« kdy: 11. 05. 2026, 12:59:53 »

Ale subjektívna je predsa celá hudba. Neexistuje objektívny hodnotiaci systém, ktorý by označil nejakú hudbu za skvelú a tú by potom na základe toho počúval každý a mal na ňu rovnaký názor.

Vždy záleží na tom, ako kto danú skladbu vníma a čo mu tá skladba prináša. Môže sa to týkať nejakých emócií alebo iba toho načesaného hluku.

Ja osobne si myslím, že je lepšie, keď sa to týka emócií a v tom prípade je lepšie, keď hudbu vytvoril niekto, kto emócie tiež má a niečo tou hudbou vyjadruje. Nebol by som prekvapený, keby hudba bola prvotne vyjadrením niečoho. A hudbou sa vždy vyjadrovali ľudia. To až oveľa neskôr sa z hudby stal ešte aj komerčný produkt.

To, že existuje hudba vytvorená umelou inteligenciou, že je dostupná a že ju niekto dokonca možno počúva, pre mňa osobne nie je vôbec dôležité. Aj keby mala byť kompozične a technicky skvelá. Iba by mala existovať povinnosť takú produkciu jasne označiť, aby sa jej dalo s minimálnymi nákladmi vyhnúť.

A že je všade? Asi v ničom v súčastnosti nie je taká miera nadprodukcie ako v hudbe. Ešte možno vo videách na YouTube.

Jo jo, celé je to subjektivní. Takže rozlišování na hudbu a hluk mi ani nic užitečného neřekne.

Jinak komerční produkt to byl +- od dob, kdy se tou hudbou někdo začal živit. Od té chvíle se jakékoliv vyjadřování čehokoliv pohybuje v mezích, kdy je za to dost posluchačů ochotných platit.
A občas raději nechci ani přemýšlet, jestli se někdo snažil opravdu něco vyjadřovat, nebo je to spíš kalkul a sázka na to, co chce obecenstvo slyšet. Takže se obvykle omezuju na to, co to dělá se mnou.

Ona ta hranice mezi lidskou a umělou hudbou nebyla úplně ostrá už před AI. Jak moc se AI hudba liší od toho, když si někdo nakliká symfonický orchestr ze samplů a své kokrhání prožene přes autotune?

6

Studium a uplatnění / Re:Kam odejít z IT v době AI?

« kdy: 11. 05. 2026, 11:54:19 »

... Neumí skládat hudbu a texty písní. ...

Mrknul jste někdy poslední dobou na Youtube a podobně? Protože AI generované hudby jsou tam mraky. Nejsou to sice  mistrovská díla, ale kvalita +- odpovídá standardní masprodukci.

Psal hudbu. O načesaném hluku se nezmiňoval.

Jenže pak do toho načesaného hluku padne i většina toho, co před AI nagenerovali lidi. A rozlišovat to je strašně subjektivní.

7

Studium a uplatnění / Re:Kam odejít z IT v době AI?

« kdy: 11. 05. 2026, 10:18:25 »

... Neumí skládat hudbu a texty písní. ...

Mrknul jste někdy poslední dobou na Youtube a podobně? Protože AI generované hudby jsou tam mraky. Nejsou to sice  mistrovská díla, ale kvalita +- odpovídá standardní masprodukci.

8

Software / Re:Licencování softwaru s výjimkou nedemokratických režimů

« kdy: 24. 04. 2026, 09:42:50 »

Krásný příklad, jak to dopadne, je knihovna glm. Tam autor vylepšil MIT licenci o

Restrictions:
 By making use of the Software for military purposes, you choose to make a
 Bunny unhappy.

Vojenským účelům je to samozřejmě úplně šumák. Problémy měli jen zaměstnanci korporátů, kde je právníci s nějakou nestandardní licencí poslali do háje. Takže teď je ta knihovna i pod normální MIT licencí.

9

Bazar / Prodej knih

« kdy: 11. 04. 2026, 11:50:01 »

Ahoj, uklízel jsem knihovnu a mám tu pár přebytečných knih.
Mistrovství v c++ od Praty, rok 2001
Moderní programování v c++, Alexandrescu 2004
C++ 101 programovacich technik, Sutter a Alexandrescu 2005
Elektronika od Lánicka 1998
Elektronika od Matatka 1987

Všechno je to staré, takže v Brně za odvoz a jinam za poštovné

10

Vývoj / Re:Jak děláte code review?

« kdy: 09. 04. 2026, 11:20:45 »

Takze vlastne devel/main branch je stale rozbita?

Naopak... je porad releasable.

On je tam nezanedbatelný překryv. A záleží primárně na podmínkách ve smlouvách, míře monopolního postavení a dalších nesoftwarových věcech.
Standardní euly pro plebs se přece píšou tak, aby bylo releasnutelné úplně cokoliv.

11

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

« kdy: 19. 03. 2026, 10:16:36 »

Váš kousek kódu může mít nedefinované chování kvůli aliasingu.

A to prosím kde/jak?

Tohle

Kód: [Vybrat]

uint32_t x = 1;
uint8_t *p = (uint8_t  *)&x;
je ok jen pokud je uint8_t typedef na unsigned char. C zaručuje jen to, že uint8_t je nějaký 8b int. Že je to character, který může aliasovat, zaručené není.

Dlouho byl unsigned char jediný standardní typ, na který ten typedef mohl rozumně vést. Ale C23 přišlo s _BitInt. To už zní dost lákavě na to, aby tou cestou někdo zkusil jít. Protože díky tomu aliasingu se uint8_t hůř optimalizuje.
Třeba tady kdysi probírali, jak by se dalo uint8_t oddělit od charu:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66110

Jo, jsou to hypotetické obavy. Ale tak je to s UB v C vždycky. Lepší optimalizátor začne využívat další možnosti a najednou se to rozbije.

12

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

« kdy: 17. 03. 2026, 08:04:08 »

Tak jakto že The C Programming Language od Kernighana a Ritchieho z roku 1978 zmiňuje preprocesor?

Zmiňuje preprocesor jako separátní tool. Těsnější integraci udělal AFAIK až clang. Pořád si pamatuju ten kvalitativní skok v chybových hláškách, když překladač najednou mohl vypsat i jména maker.

Některé lovy bugů si pamatuju fakt dobře, protože byly fakt drsné. Překladač vidí úplně jiný kód než vy a preprocesor vás ubije k smrti kvanty textu.

To je prosím celá mrtě logika, která je potřeba pro detekci endianity buildtoolem - ten checkne návratový kód.
...

Nee, ta logika je celý ten autotools ansábl, který ošahává překladač aby tím mohla nakrmit preprocesor.

Je to takové Cčkovské. V C můžeš udělat cokoliv, stačí když to celé uděláš sám. C ti hlavně nastaví vidle.

Přeložit a spustit testovací kousky programu a výsledkama nakrmit preprocesor by šlo použít u jakéhokoliv jazyka. C v tom figuruje jen tím, že nikde jinde takovéhle divočiny nepotkáte. Protože to dává smysl jen když nic lepšího není k dispozici.

C je všude, protože je navržený tak, aby se pro něj jednoduše psaly překladače. Všechno ostatní je tomu podřízené.

Linux je nejpřenositelnější OS jaký existuje No a nemyslím si že používají GCC kvůli tomu že by C nebylo přenositelné.
 Inline assembler je spíše praktická věc pro OS kód. Různé builtin funkce jsou spíše optimalizační techniky. Makro typeof zase umožňuje generičtější kód, což jenom šetří psaní... dalo by se bez toho všeho obejít. Které věci z GCC dialektu jsou striktně kvůli přenositelnosti bez kterých by se nedalo obejít?

Dialekt není jen o rozšířeních. Je třeba i o zalepeném nedefinovaném chování. Váš kousek kódu může mít nedefinované chování kvůli aliasingu. Ve standardním C by se to muselo napsat jinak. Ale autotools samozřejmě řeší přenositelnost jen v rámci gnu světa.

13

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

« kdy: 13. 03. 2026, 11:13:36 »

to mi pripomelo kompilator, ktery generuje pouze move instrukce.

https://github.com/xoreaxeaxeax/movfuscator

Ten "single instruction" nadpis otvírá zajímavou teoretickou otázku, "Co je to vlastně ta 1 instrukce?"

Protože ten mov má hromadu variant, co dělají i docela odlišné věci. Už jenom "load" a "store" jsou tak odlišné věci, že pro to mají některé architektury různé instrukce.

14

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

« kdy: 13. 03. 2026, 09:10:11 »

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.

Čistě teoreticky by se tady dala vytáhnout rodina x86 procesorů. Kdy stejné instrukce assembleru můžou být zakódované pomocí mnoha různých opkódů. A staré procesory umí některé, které už nové neumí a naopak.
Ale prakticky se pořád mluví o x86 instrukční sadě.

15

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

« kdy: 13. 03. 2026, 08:53:17 »

A jak souvisí překladač, platforma, verze a nebo název makra s tím jestli je jazyk přenositelný? Toto makro má nakonfigurovat build systém a předat ho překladači.

V režii jazyka už pak je jenom podmíňěná kompilace na tu nebo onu variantu.
...

Tu podmíněnou kompilaci ale nedělá jazyk C ale C preprocesor. Je to separátní tool, který ani nerozumí kompletní syntaxi C a používá se i pro jiné jazyky. Integrace preprocesoru do překladače proběhla až relativně nedávno, protože to oddělení mělo nepříjemné důsledky na použitelnost.

Ve chvíli, kdy build systém chystá makra pro preprocesor, tak je přenositelný úplně každý jazyk. Abych dostal to makro ENDIANESS tak musím mít někde mrtě platformně závislé logiky. Protože sám jazyk C v tom pro mně neudělá ani ň.

Btw, drtivá většina C kódu není přenositelná, ale je psaná v nějakém platformně závislém dialektu. Je to proto, že v přenositelné podmnožině C chybí naprosto zásadní věci. Např linux není psaný v C ale v GCC dialektu a při portování do clangu se do něj ten GCC dialekt přidal.