Příspěvky

1

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

« kdy: 11. 10. 2025, 16:36:07 »

V každém DB serveru bylo mnoho clusterů v jedné DB...

Spíš naopak, ne?

Napsal jsem to nepřesně, myslel jsem mnoho clusterů na jednom DB serveru ve smyslu instalace PostgreSQL. A potom také mnoho jednotlivých databází v každém clusteru.

2

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

« kdy: 09. 10. 2025, 14:09:27 »

Obecně automatická instalace clusteru na Debianu mi přišla vždy jako dost nepraktický nápad

My jsme si to naopak nemohli vynachválit. V každém DB serveru bylo mnoho clusterů v jedné DB, Debianí příkazy fungovaly (problém je, pokud to někdo kombinuje). Lze mít i více verzí a update na novou verzi je opět jedním příkazem. Takto jsme migrovali hromadu databází v podstatě live.

Ono by to šlo samozřejmě i jinak, ale v Debu je to všechno už napsané.

Třeba ve FreeBSD také není automatický initdb a defaulty je potřeba nastavit hned po instalaci. Je to více manuální, ale zase si to člověk může automatizovat dle situace.

3

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

« kdy: 03. 10. 2025, 16:53:03 »

Obávám se, že když někdo neví, v jakém kódování má která data, tak ho nezachrání ani knihovna.

Knihovny v jazycích, které jsem používal, používaly zásadně unicode, takže nepořádek ve stringu by musel být už před tím. Stejně je s podivem, že se dneska ještě používá ISO nebo starší kódování. Pokud je celý program v unicode, tak se tam špatný text v podstatě zadat ani nedá, to by to tam musel někdo špatně už napsat.

4

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

« kdy: 01. 10. 2025, 17:43:26 »

Objektové jazyky jsou asi nejflexibilnější – byť s jinou syntaxí, v nich můžeš realizovat to, co jinde.

Nejflexibilnější jsou jazyky s otevřenou minimalistickou syntaxí, v nichž si mohu dotvořit, co potřebuji - jako LISP, FORTH, TCL... Ani jeden z nich nebyl vytvořen jako objektový, v žádném z nich ale není problém objektový systém dotvořit, když bez něj někdo nemůže žít (což se i stalo; obzvláště CLOS je podle mě nejméně o level lepší objektový systém, než jaký nabízí C++, C# nebo Java). Ale jazyky tohoto typu IMHO objektové nadstavby nepotřebují, protože samy o sobě umožňují vytváření tak silných výrazových prostředků, jaké si jen autor programu přeje a potřebuje k řešení svého problému, takže proč se omezovat na objekty.

Mám pocit, že pro jazyky s multimetodami nikdy nevznikla efektivní implementace. Nebo ano?

Nevím přesně co tím myslíš. Psal o tom pan Tišnovský v roce 2016 a jazyku Clojure. Podle popisu to vypadá na podobnou věc, jako je v golangu tzv. func receiver. Tedy možnost si připsat metodu do objektu syntaxí

(object)Method(args)

Takto se do object dostane další metoda v rámci aktuální package. Každý package si může definovat jinou vlastní metodu pro sdílený objekt.

5

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

« kdy: 01. 10. 2025, 15:20:38 »

Jak kde. Postupem času jsem došel k tomu, že 1) implementaci, která je skrytá uvnitř, je většinou dobré dělat co nejjednodušší, nedělat overengineering, nevyrábět tam za každou cenu X objetků nebo abstraktních rozhraní, když stačí pár obyčejných metod, pár bloků kódu. Protože tyhle implementační detaily můžeš kdykoli přepsat a udělat je složitější nebo „pořádně objektově“. Ale u 2) veřejného rozhraní bys měl ten návrh udělat robustní už na začátku a myslet (v nějakém rozumném horizontu) i na budoucí vývoj a obecnost, univerzálnost. Protože veřejné API bys měl měnit co nejméně a hlavně zpětně kompatibilně (pokud nechceš naštvat všechny kolem sebe).

Více jsem to rozepsal v Rozlišování veřejného API a interních rozhraní.

Jo, v tomto se shodujeme. Já jsem reagoval na tu univerzální váhu akce::zvazit(osoba, vaha) - tohle je kravina, proč by metoda zvážit měla dostat ještě další obecnou metodu váha? (A prosím, programujme pouze anglicky.)

To, že se veřejné API nemění se nemusíme ani bavit, ale tady je přece diskuse o implementaci. Všechny jazyky mají něco jako interface, golang má bohaté datové typy z možností si jich udělat kolik potřebuju, k tomu definovat metody rozhraní a potom si to každý může naimplementovat jak potřebuje. Stačí dodržet signaturu rozhraní a typy (ty jsou definované v předávaných parametrech rozhraní). Možná mám moc rád golang, ale tohle je přesně to, proč mám rád i PostgreSQL a jeho bohatství datových typů a jejich omezení (referenční integrita, constraints apod.). Prostě teplota v Kelvinech je vždy větší než nula apod.

6

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

« kdy: 01. 10. 2025, 14:49:55 »

Kód: [Vybrat]

vaha.zvazit(osoba)
osoba.zvazitSe(vaha)
Oboji je spatne. Melo by to byt akce::zvazit(osoba, vaha) - a je to. Osoba nemusi znat nic o vaze, a vaha muze umet vazit treba i zvirata nebo mouku.

Cele OOP je do jiste miry divne, nuti nas vazat akce na konkretni objekty, ktere by klidne mohly byt naprosto nezavisle.

Tohle ale záleží na konkrétním programu. Kevlin Henney (https://en.wikipedia.org/wiki/Kevlin_Henney) doporučuje každý program dělat maximálně konkrétní, tedy pro tiskárnu je normální mít datové typy jako ink, paper, book apod. Je nevhodné vytvářet abstraktní metody, které umí vážit slona, když potřebuju jen znát hmotnost inkoustu. Tiskárna ví, kolik ho potřebuje a datový objekt typu ink může mít metodu GetVolume(). Nebo ještě lépe, mít kontejner pro inkousty a o každém ví, kolik jaké barvy tam je.

7

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

« kdy: 30. 09. 2025, 12:09:05 »

Ale co třeba takové:

Kód: [Vybrat]

vaha.zvazit(osoba)
osoba.zvazitSe(vaha)
Je něco z toho zjevně dobře nebo zjevně špatně?

Pokud objekt osoba zná svou váhu, tak je lepší osoba.GetVaha(). Odděluje se dotaz a vykonání, takže metoda ZvážitSe() nemá nic vracet, jen měnit vnitřní stav objektu. Tohle se odděluje proto, že při každém dalším volání ZvážitSe by se to počítalo znovu a možná s jiným výsledkem. Zásadně se odděluje část vykonání něčeho a vracení výsledku.

Stejně tak předávat váze objekt Osoba je často kravina. Ta metoda může být součástí osoby nebo získaná přes implementaci interface (třeba Golang) nebo přes dědění (Java, C++). V Golangu se ani neřeší interface (jeho jméno), prostě stačí definovat jeho metody a objekt může mít implementováno tolik rozhraní, kolik je potřeba.

8

Hardware / Re:Externí disk odolný proti odpojení

« kdy: 29. 09. 2025, 11:02:47 »

Windows takhle disky připojené přes USB připojují automaticky.

Díky za info, tohle je užitečné.

9

Hardware / Re:Rozdílné barvy na monitorech Dell a Mac

« kdy: 29. 09. 2025, 11:00:27 »

Jak už bylo napsáno, monitor je OK a PC je standard, který umí i MAC. Jde spíš o to, jestli je pro monitor nastaven správný barevný profil (každý OS potřebuje vědět na co zobrazuje). Něco se přenáší před EDID, ale to se nemusí přenést přes převodníky. 8b monitor musí umět zobrazit každou barvu.

10

Sítě / Re:Optika od Cetinu - jen pro O2?

« kdy: 28. 09. 2025, 10:46:08 »

Tomáš Crhonek:
Záleží komu ta optika patří. Co vám řekli z O2? Zkoušel jste svou adresu hledat přes Cetin?
Proč jste pokaždé hledal switch na Cat5e kabel?

Já jsem žádný switch nehledal, ten hledal technik od O2. CETIN není pro koncové zákazníky.

11

Sítě / Re:Optika od Cetinu - jen pro O2?

« kdy: 27. 09. 2025, 09:56:55 »

U nás v domě mám optiku na chodbě za jednou zdí. Dvakrát jsem chtěl optiku až domů (FTTH) a pokaždé hledal switch na Cat5E kabel. Přitom lze mít optiku v SPF konektoru klidně doma. Takže nevím, co O2 nabízí, ale mě prostě nepřipojili.

12

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

« kdy: 27. 09. 2025, 09:53:53 »

Rust znám jen z přednášek, já jsem přešel na golang. Je jednodušší a má výborné možnosti multithredingu.

13

Hardware / Re:Externí disk odolný proti odpojení

« kdy: 27. 09. 2025, 09:53:08 »

Stále je možnost připojit disk se sync options, je to bezpečné, data jsou okamžitě na médiu, ale je to přirozeně pomalé. Jak psal Filip, pokud aplikace nedodržuje pořadí a nevolá fsync nebo fdatasync, tak poslední zapisovaný soubor bude rozbití. Všechny FS přežijí odpojení disku.

14

/dev/null / Neschopnost O2 připojit zákazníka k TV

« kdy: 11. 09. 2025, 18:33:54 »

Ahojte,

mám kámoše a ten má bohužel O2 a ne někoho normálního a nefunguje mu televize. Na O2 lince nejsou SCHOPNÍ telefonovat a musí za ty zcela neschopné zaměstnance volat AI. Takže, za mě, okamžitě zrušit O2 a všechny neschopné zaměstnance okamžitě vyhodit bez možnosti další práce.

Už jsem psal na ministerstvo vnitra a do EU aby okamžitě zakročila nebo O2 okamžitě bez náhrady zrušila.

Jaké máte zkušenosti vy? Nám šlo volat i ve 3 ráno a dneska jsou neschopní dokonce i telefonovat přes den.

15

/dev/null / Re:AI hra jako simulátor státu – myšlenka, která by mohla učit i inspirovat?

« kdy: 09. 09. 2025, 19:00:57 »

Za mě super nápad a takovou hru si určitě koupím.