Příspěvky

1

Desktop / Re:Zkušenosti s nasazením LibreOffice Base

« kdy: 12. 02. 2026, 08:40:37 »

Moje účetnictví provozuji v libre calcu - na moje věci to bohatě stačí - hodila by se mi ale nějaká automatizace na generování kontrolních hlášení. Zase faktur mám tak málo, že mne to ještě nedokopalo, do přepsat. Asi by to šlo nějak i přímo v Libre calcu, ale to jejich skriptovací prostředí mi nesedí.

Roky pokukuju po https://gambaswiki.org/website/en/main.html

V podstatě je to analogie Visual Basicu, kde se tyto malé věci docela dobře dělaly - stejně jako v Delphi, .NETu a dalším. Tam bude minimální rozdíl ve funkčnosti - a každému sedí trochu něco jiného.

2

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

« kdy: 08. 01. 2026, 21:28:00 »

V poslední době je vidět, že uživatelé trochu agilněji reportují bugy - i s nástřelem analýzy a možné opravy.

Nicméně v jednom případě šlo o chybu v jiném produktu, a ve druhém případě analýza byla mino, a nástřel opravy by chybu jen zamaskoval a spadlo by to na dalším místě. Za mne zatím AI generuje víc práce, protože bug report je delší, vypadá realisticky, ale obsahuje dost blbostí.

3

Software / Re:Má vůbec smysl reportovat někam chyby?

« kdy: 26. 12. 2025, 19:38:03 »

Reportovat můžete, ale čím máte starší hardware, tím je menší šance, že se něco fixne. Může to mít smysl. Čím víc lidí reportuje problém, tím možná mu někdo dá vyšší prioritu. Je ale jasné, že někdy podpora musí skončit.

Já osobně mám dost pozitivní zkušenost - mám Lenovo T520 - teď mu bude 15 let. Kernel 6.16 měl rozbitou síťovou vrstvu - nefunkční wifi, a sem tam crashe. Reportoval jsem (a nebyl jsem sám), a 6.17 běží jak víno. Před měsícem jsem instaloval Fedoru na ještě starší Dell D830 - což bude 18 letý počítač, a všechno běží. Počítač je v perfektním stavu, nicméně ty tři roky navíc jsou znát. T520 je více méně v pohode, D830 už se mi zdá pomalá. Hlavně je to ještě poctivý železo - nikam už by se mi ho nosit nechtělo.

4

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

5

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.

6

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

7

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.

8

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.

9

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.

10

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

11

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>

12

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.

13

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.

14

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

15

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