Příspěvky

1

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?

2

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

3

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.

4

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

5

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é

6

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.

7

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.

8

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.

9

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.

10

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

11

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.

12

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

« kdy: 12. 03. 2026, 12:54:01 »

Na to stačí jednoduchý #ifdef
případně runtime detekce se dá udělat taky, jak pro endianitu, tak pro dvojkový doplněk.

K ostatnímu se nebudu vracet, ale ten jednoduchý ifdef třeba na endiany bych chtěl vidět. Normálně potkávám několik obrazovek ifdefů, protože každý překladač, platforma a občas i verze mají ty makra nějak jinak.

13

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

« kdy: 11. 03. 2026, 10:58:53 »

Teprve jazyk C vyřešil přenositelnost.

V rámci možností. Pokud člověk například nepotřebuje vědět, jestli char je signed nebo unsigned. Nebo jak velký je int. Viz nedávné flame vlákno o bit shiftování signed intu.

To jsou zase plky
Pokud někdo potřebuje zajistit přesnou velikost typu přenositelným způsobem, tak na to je knihovna <stdint.h>, která je součást standardu.

Otázka do flamu. Pokud použiju separátní tool (který ani nezná kompletní syntaxi C) abych jím lepil platformně závislé kousky textu dohromady, můžu ještě mluvit o přenositelném jazyce? Protože s preprocesorem tak jde psát přenositelně i assembler.
A věci jako endiany nebo jestli mám vůbec dvojkový doplněk se zjišťují hůř. Ty jako makro naservírované nedostanu.

Jestli je něco signed nebo unsigned jazyk definuje taky - že to pak nějaký kompilátor overridne je druhá věc.

Tak zrovna u charu je to "implementation defined". Takže jazyk C definuje jen to, že to kompilátor "overridnout" prostě musí.
A proto jsou taky "char", "signed char" a "unsigned char" 3 různé typy (aby to nebylo nudné jako u intů).

A bit shift signed intu je prostě UB, tak shiftuj unsigned a taky máš přenositelný program.

Ano, v C se dá psát přenositelný kód. Ale protože je to jazyk z punkových časů, tak toho ta přenositelná podmnožina až tak moc neumí. A málo šedivé programátory to může překvapit, protože spousta těch věcí z dnešního pohledu už fakt nedává smysl.

A abych přispěl i k původní otázce, tak rozdíl mezi assemblerem a strojákem nemusí být jen ty symbolické adresy. U DSPček (myslím že to bylo nějaké TMS320) jsem potkal i to, že pipeline nebyla maskovaná. Instrukce ve strojáku byly v pořadí v jakém se cpaly do pipeliny, ne v jakém se nakonec vykonaly. Takže assembler i přerovnával instrukce (podle latence + přidával potřebné nopy) z lidsky čitelného pořadí do toho jejich hnusnopekla.

14

Studium a uplatnění / Re:Ako ste sa stali seniorom?

« kdy: 10. 03. 2026, 13:10:53 »

Vždycky jsem si myslel, že senior je někdo, kdo zná tři tech stacky od základu a umí navrhout architekturu projektu během půlhodinky mezi meetingama, ale jak mi Vás tak poslouchám, tak stačí bejt medior se znalostí projektu.

Nee, senior je někdo, kdo ví jak takové rychlokvašené návrhy obvykle dopadají.

15

/dev/null / Re:Nechali byste si do mozku implantovat čip?

« kdy: 09. 03. 2026, 12:33:14 »

Možná tě překvapím tvrzením, že již v roce 2000 měla jedna renomovaná firma hotový čip do hlavy a byla připravena ho masově vyrábět. Od té doby uplynulo již 25 let. Takže předpokládám, že technologie hodně pokročila.

Pokud už uplynulo 25 let a stále nic, tak to asi tak úplně připravené nebylo BTW "jedna renomovaná firma" zní, jako byste opravdu nechtěl, aby to někdo googlil

Na Googlu to asi nenajdete. Takže to řeknu přímo. Šlo o firmu Intel. Čip měl sloužit k ovládnutí člověka a nikoliv ke komunikaci atd. Čip měl být do lidí implantován nařízením s odůvodněním, že jde o identifikační čip a ještě něco, co si již nepamatuji. Zjistilo se však, že by to lidi nepřijali. Krom toho testovací lidi s tím čipem měli zdravotní problémy - časté a intenzivní bolesti hlavy atd.

Dnes se čipuje všechno možné: identifikační průkazy, zvířata, zboží v obchodech a dobrovolně lidi, co to chtěj.

Ovšem čipovat lidi se slibem, že z nich budou nadlidi s lepšími schopnostmi, je zvěrstvo.

Jo takhle, už začínám chápat odkud vítr fouká