Příspěvky

1

Studium a uplatnění / Re:je programatoru moc, nebo malo.

« kdy: 29. 10. 2025, 07:04:57 »

za me:

e) na trhu je moc pseudo-programtoru co nedokazou dodat vysledky
4) totalne selhava HR, ktere nerozumi problematice takze se nabiraj nemehla
juchu) podniky nedokazou udrzet core lidi - skrze vyssi odmeny a ti radeji jdou jinam a maj to pak taky na haku

Cele to je vlastne zacarovany kruh, migrujici pracovnici prozatim jsou na koni, protoze se vzdy najde nejaka zoufala firma kde se lze upichnout, ale nebude to trvat dlouho a tento system se zhrouti. (A nebo taky ne, a efekt upadku se tem korporatum ktere jsou "too big to fail" povede dostatecne snizit, aby updaek nastal az pozdeji.. po nas potopa system).

Byt mimo tento system je vlastne celkem fajn.

Vidím to stejně.

2

Studium a uplatnění / Re:je programatoru moc, nebo malo.

« kdy: 29. 10. 2025, 06:58:37 »

Ta anketa trochu fabuluje v tom, že open source píší dobrovolníci ve svém volném čase, a když nejsou dobrovolníci, není ani open source.

Drtivou většinu kódu v open source napsali normálně placení programátoři. Sem tam něco napíše i nějaký dobrovolník, ale to je přištipkaření, sem tam přijde trochu zajímavého kódu z univerzit. Gro kódu ale psali a píšou programátoři, kteří byli někým zaměstnáni a placeni. Pokud někde na nějakém projektu nejsou lidi, tak to primárně znamená, že ten projekt je investičně nezajímavý. Priority investorů se samozřejmě mění - dneska to bude nejspíš fintech, AI, drony než desktop.

3

Studium a uplatnění / Re:je programatoru moc, nebo malo.

« kdy: 29. 10. 2025, 06:27:56 »

Programátorů je dost, ale jejich pozornost a motivace je jinde.

Unity byl dřív komerční projekt - většina komerčních projektů zanikne, když se do nich přestane investovat.

Ono to není jen o penězích a počtech programátorů. Resp. tyhle faktory hrají spíš menší roli než větší. Hodně je to o kvalitě kódu, jeho velikosti, komplexitě, popularitě projektu, kultuře v komunitě, jestli jsou nebo nejsou v komunitě kvalitní programátoři, kvalitní kodéři, jak si moc sednou nebo nesednou lidi v týmu, jak se dokáží doplňovat, jak na sebe dokáží navazovat, jestli jsou komunitě i méně kvalitní programátoři, kteří dokáží udělat přípravu a napsat PoC (případně dělat reviews). Těch faktorů je mnohem víc, mění se v čase, tak jak se mění svět, technologie, stárnou lidi, zvětšuje se kód.

Programování je umělecké řemeslo (někdy víc řemeslo než umělecké). Pokud se hlavě nechce, tak sebelepší programátor nenapíše jedinou řádku - je to hodně o vnitřní motivaci. Čím je větší projekt, tím náročnější je jeho údržba. Čím má projekt víc uživatelů, tím může být náročnější je všechny uspokojit, tím náročnější může být najít nějaký kompromis. V určitý moment je potřeba udělat zásadní přepis kódu, a to je naráz výrazně víc práce a starším se do toho vůbec nemusí chtít (protože ví co je to za "neproduktivní" a náročnou práci), pro mladé to může být příliš náročné a nezajímavé. Není to jen o investicích a množství lidí.

4

Server / Re:PostgreSQL 18 neinicializuje databázi při instalaci

« kdy: 08. 10. 2025, 11:53:54 »

A tohle je v debu nejaka novinka? V Gentoo se to takhle chova co pamatuju. Akorat ti to teda slusne vypise, ze pokud chces inicializovat novou db, tak o to jeste musis rict.

Na RH se cluster musel inicializovat vždy - příkazem `postgresql-setup initdb`. Obecně automatická instalace clusteru na Debianu mi přišla vždy jako dost nepraktický nápad - možná užitečný pro začátečníky, ale jinak naprd, protože se cluster buildil se špatnými defaulty (které možná mohly někomu vyhovovat) - pro naše prostředí chybné výchozí collate, a v posledních letech je spíš chybou nezapnout checksumy pro datové stránky. Takže rada pro Debian bylo nainstalovat Postgres, zastavit ho, smazat výchozí cluster, a vytvořit ho znovu se správnými defaulty. Debianní skripty jsou možná 20 let staré, takže těžko to zgruntu předělávat - a každá změna někoho naštve a někomu hodí klacek pod nohy.

5

Server / Re:PostgreSQL 18 neinicializuje databázi při instalaci

« kdy: 07. 10. 2025, 14:54:29 »

Cau,

setkavam se s tim opakovane, ale nedohledal jsem zatim zadnou informaci ohledne tohoto. Instalace postgresql 18 v debianu z repozitare apt.postgresql.org oproti predchazejicim zpusobuje toto:

1] pokud na (treba) VM neni zadna predchozi instalace libovolne verze postgresql, inicializuje se databaze + konfigurace
2] pokud na te same VM je predchozi instalace libovolne verze postgresql, NEinicializuje se databaze + konfigurace

Proc a jak z toho ven? Pan Stehule by mohl vedet?

Diky

Nevím o tom nic, a ani si nevybavuji, že by k tomu byla nějaká diskuze. Tohle je záležitost lidí, kteří dělají na debianu balíčky pro Postgres - podle man Martin Pitt <mpitt@debian.org>, Christoph Berg <myon@debian.org>. Tak jim zkuste napsat a zeptat se. Myslím si, ale nevím, že by to mohlo souviset s preferencí upgrade přes pg_upgrade místo pg_dumpu. Pokud chcete vytvořit novou instanci Postgresu, tak na debianu by se měl použít příkaz pg_createcluster https://manpages.debian.org/unstable/postgresql-common/pg_createcluster.1.en.html - což je obálka nad initdb.

6

Vývoj / Re:Je jazyk C skutočne ťažký?

« kdy: 08. 06. 2025, 08:56:42 »

Konkrétně signed integer overflow zkoumají pod AO3 (vypnuli to pomocí -fwrapv) a rozdíly ve výkonu jsou zanedbatelné.

Ono je otázkou, co je dneska implementovatelné v překladači z pohledu zpětné kompatibility a očekávání uživatelů.

V každém případě moderní překladač důrazně upozorní, že je něco jinak, a je na vývojáři aby napsal kód bez warningu. V Postgresu kód s warningem nemá šanci se dostat do upstreamu, a co jsem se jako vývojář naučil, že warning v Cčku není něco, nad čím by se dalo mávnout rukou.

7

Vývoj / Re:Je jazyk C skutočne ťažký?

« kdy: 08. 06. 2025, 05:49:20 »

Zkus tohle chování vysvětlit. Pokud možno _jednoduše_, když je C jednoduchý jazyk. 

Když to přeložím bez optimalizací - na gcc 15.1, vypíše to 4 čísla. Když to zkusím s optimalizací

dostanu zřetelný warning:

<code>
    test.c: In function ‘main’:
    test.c:7:9: warning: iteration 3 invokes undefined behavior [-Waggressive-loop-optimizations]
        7 |         printf( "%d\n", i*1000000000 );
          |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    test.c:6:20: note: within this loop
        6 |  for (int i = 0; i < 4; ++i)
          |                  ~~^~~
</code>

Je to docela dobře vysvětlené https://stackoverflow.com/questions/24296571/why-does-this-loop-produce-warning-iteration-3u-invokes-undefined-behavior-an .

Holt optimalizace v C jsou opravdu agresivní - a opravdu se v Cčku nevyplatí ignorovat warningy

8

Vývoj / Re:Je jazyk C skutočne ťažký?

« kdy: 08. 06. 2025, 05:36:03 »

Zkus tohle chování vysvětlit. Pokud možno _jednoduše_, když je C jednoduchý jazyk. 

Když to přeložím bez optimalizací - na gcc 15.1, vypíše to 4 čísla. Když to zkusím s optimalizací

dostanu zřetelný warning:

<code>
    test.c: In function ‘main’:
    test.c:7:9: warning: iteration 3 invokes undefined behavior [-Waggressive-loop-optimizations]
        7 |         printf( "%d\n", i*1000000000 );
          |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    test.c:6:20: note: within this loop
        6 |  for (int i = 0; i < 4; ++i)
          |                  ~~^~~
</code>

9

Vývoj / Re:Programovací jazyk Ada v České republice

« kdy: 29. 04. 2025, 08:17:17 »

Zajímal jsem se o to, proč Ada dopadla tak jak dopadla, reálně působí informace, že dlouho nebyl k dispozici zadarmózní kompilátor narozdíl od C/C++ a pokud školy přestaly Adu vyučovat, situace nemohla dopadnout jinak. Proto je hlavní procento knížek do roku 1995 (Ada 95 Problem Solving Program Design, Ada 95 from the Beginning, Ada 95 The Craft of OOP), z novějších už jen Beginning Ada programming from novice to professional 2020 nebo nesmrtelný Barnes se svojí nejnovější Programming in Ada 2022. Co se dá dělat, takový je vývoj.

Podle mne to zazdila licence, a možná příliš velké ambice, možná načasování. Wirth v 90 letech propagoval dost minimalistické jazyky - např. Oberon. Možná tam svoji roli hrála skutečnost, že v C byly psané Unixy, později Windows byly napsané v C++, a v druhé polovině 90 let přišla Java, které měla moderní knihovny pro práci s TCP - a pro experimenty s internetem byla vhodnější. V 80 letech ještě nebylo tolik výkonu nazbyt, a přeci jen C je tomu assambleru blíž, a je jednoduší v něm psát rychlé aplikace. O tom jestli nějaký programovací jazyk se rozšíří nebo ne rozhoduje dost možná náhoda, třeba i v tom jestli nějaká významná a velká firma podporuje a používá daný jazyk -  a zbytek se opičí. To, co se děje na univerzitách (a co se tam učí) zas až tak velkou váhu nemá (spíš pak některé koncepty se díky tomu dostanou do mainstreamového jazyka). Většina firem, managmentu se dost nerado odchyluje od aktuálního mainstreamu.

10

Vývoj / Re:Programovací jazyk Ada v České republice

« kdy: 28. 04. 2025, 21:16:30 »

Algolské jazyky však v programátorském světě nemají štěstí, což potvrzuje mnoho reakcí diskutérů u článků o tomto jazyce zde na Rootu.


Proto bych se rád touto cestou optal, zda se některý ze čtenářů nesetkal s tímto jazykem ve firemní praxi nebo nezná někoho, kdo ano.

Asi záleží na generaci a škole. U nás (začátek 90 let - ČVUT) byl Pascal dost preferovaný, při výuce, při psaní aplikací. Naopak C nebo C++ měl příchuť punku. Na Matfyzu prý jelo C++. Osobně mám Wirthovy jazyky rád - i když už jsem je nikdy nepoužil - Modula, Oberon nebo Visual Basic (upravená Modula).

Dost lidí stále používá variantu ADY aniž by o tom vědělo. PL/SQL (Oracle) je docela věrná implementace ADY. A v PL/SQL jsou stále napsané milióny řádků procedur běžících v apkách v korporátech. PL/pgSQL (Postgres) je osekaná kopie PL/SQL - takže je to taky trošku ADA.

11

Server / Re:Používá se ještě databáze Firebird?

« kdy: 27. 04. 2025, 08:28:00 »

Jestli nedošlo ke změně, tak nad Firebirdem běží Pražská Městská knihovna. Osobně Firebird nepoužívám, a zrovna tak neznám nikoho, kdo by ho používal, ale po očku sleduji vývoj. Je to databáze, která má relativně stabilní letitý vývoj, který je stále živý, a má to svojí niku. Je to databáze vhodná pro embedding - nakopírujete 2 soubory a jedete, má to vlastnosti, které zjednodušují vývoj v embeddingu. V tom je to stejná databáze, jako je SQLite. Oproti ní je to ale databáze - s plnohodnotným SQL, s vestavěným skriptovacím jazykem, monitoringem. SQLite (i podle vlastního vyjádření jejího autora) je spíš transakční filesystém s SQL API. SQLite je primitivní (ale pro řadu použití dostačující) jednouživatelská velice malá databáze. Oproti tomu je Firebird úplná více uživatelská databáze (i když se spíš jen výjimečně používá pro větší počet uživatelů), která je ale stále velmi malá a kompaktní (vhodná pro embedding), což Postgres nebo MySQL třeba určitě není.   Pokud bych předpokládal, že s nějakým hw budu distribuovat i databázi, tak pravděpodobně bych šel do Firebirdu (zvlášť pokud bych měl někoho, kdo s ním umí).

12

Server / Re:Nevýhody InnoDB oproti MyISAM v MariaDB

« kdy: 18. 04. 2025, 20:34:05 »

MyRocks (MariaDB only)   Designed for write-heavy workloads, MyRocks is optimized for crash resilience but might not be suitable for all use cases.

Jestli má MyRocks a Aria stejné nedokumentované nedostatky jako MyIsam co se týče paralelního čtení a zápisů se nelze nikde dočíst.

MyRocks by mělo být postavené nad RocksDB - https://github.com/facebook/mysql-5.6/wiki/Getting-Started-with-MyRocks

rockdb podporuje neblokujici snapshoty - tudiz by cteni nemelo blokovat zapis https://github.com/facebook/rocksdb/wiki/rocksdb-faq

13

Studium a uplatnění / Re:Prerspektivy studia IT ve světle současného vývoje AI

« kdy: 17. 04. 2025, 22:18:00 »

Ahoj vsichni,
jak vidite aktualni perspektivu VS studia oboru IT (napr. VUT FIT) ve svetle soucasneho velmi rychleho zvysovani vykonu AI, na to navazanych ruznych copilotu a dalsich vyvojarskych prostredku jako je napr. Claude Sonnet + Cursor AI IDE, atd...atd.... a proste celkoveho rustu analytickych schopnosti AI?
Jaka je podle vaseho mineni ve vyhledu nasledujicich par let perspektiva vyvojaru, coderu, databazovych specialistu, ale treba take i adminu, protoze i prace admina je zalezitost, kterou AI nepochybne v kratkodobem vyhledu bude zvladat levou zadni.
Pred par dny byl vydan ChatGPT 4.1. Priznam se, ze jeho schopnosti me docela ohromily. Pripada mi evidentni, ze AI bude schopna nahradit nejen rutinni prace, ale take samostane vyvijet i slozite algoritmy.
 
Jen mi to tak pripada a nebo se o teto zalezitosti hovori naprosto nedostatecne?
Jak se na tohle tema divate vy? Ktere obory IT zatim i v dlouhodobejsim vyhledu dle vaseho nazoru zustanou lidskou domenou?

AI neumí nic vytvořit - umí jen kombinovat. Nicméně drtivá IT není o programování složitých algoritmů.

I bez AI se v posledních 10 letech do IT dostalo mraky lidí, což vede k tomu, že juniorní mzdy v IT budou spíš dolů nebo stagnovat. Navíc je na obzoru docela velká ekonomická krize. Vždy záleží na kvalitě - velice dobrý junior si práci najde, možná ne tak snadno jako před 5 roky, ale najde. Průměrný junior si práci nenajde. Věřím tomu, že platy se trochu srovnají - už teď šikovný klempíř si rukama vydělá víc než průměrný ajťák, a nevidím důvod proč by se to mělo měnit - školy teď chrlí ajťáky ne klempíře.

14

Server / Re:Nevýhody InnoDB oproti MyISAM v MariaDB

« kdy: 17. 04. 2025, 22:03:28 »

Mám ZFS, takže některé ochranné prvky, které dělá innoDB jsou zbytečné, protože jsou dělány na úrovni souborového systému.

ZFS je dost pomalý filesystém - a při velké zátěži jsou s ním s databázemi problémy. MyISAM neřeší konzistenci - zápisy končí ve filesystémové cache - a v případě havárie můžete příjít o data z filesystémové cache - což vzhledem k primitivnímu formátu nemusí být problém - můžete mít ale nakopnutý index, a to už problém být může. InnoDB má mnohem složitější formát a pokud by došlo ke ztrátě konzistence, tak to není jen o ztrátě pár záznamů. ZFS vám pomůže jen v tom, že si můžete udělat snapshot a vrátit se k nějakému snapshotu. Pokud by se ale rozbila konzistence v MySQL, tak je vám ZFS na dvě věci. InnoDB má na rozdíl od MyISAM vlastní write cache - o kterou v případě havárie můžete přijít, a tak musíte mít konzistentní transakční logy. Pokud byste je neměl, tak to, že přijdete o pár záznamů je to nejmenší - můžete mít nakopnutý index, což rozbije vyhledávání - unikátní index nemusí být unikátní, atd atd. MyISAM je do jisté míry "inmemory db", takže některé operace mohou být velice rychlé. Má velice primitivní formát - který je relativně odolný vůči chybám. InnoDB funguje už úplně jinak, a případné chyby konzistence v InnoDB mají mnohem horší dopad.

15

Bazar / Re:Nabízím instalačky MS-DOS 3.3 a antiviru Tři psi

« kdy: 04. 04. 2025, 12:00:03 »

Mimochodem, neví někdo z pamětníků, kteří si na Tři psy ještě vzpomínají, v čem byli naprogramováni? Na obrázcích to vypadá trochu jako Turbo Vision, ale barevnostně je to jiné. Snad nějaký Basic...

V zásadě to mohou být Turbo Vision. Ty třídy se dají upravit.
Ale silně to připomíná interface, který měly utility od Nortona. Takže by to mohla být nějaká knihovna, která byla součástí Zortech aka  Symantec C++.

Myslím si, že 602 měla vlastní GUI knihovnu, kterou používala v 90 letech ještě před přechodem na Win. Byl v tom napsaný i calc602 https://lukas.faltynek.com/2007/03/05/c602_ceskoslovenska_konkurence_ms_excel/. V těch dobách skoro každý povinně si podobnou okýnkovací knihovnu napsal - případně se daly sehnat jako freeware. V čem to bylo napsané, netuším - autoři ale měli sklon k Pascalu - i interní skriptovací jazyk byl Pascal.