Příspěvky

1

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

« kdy: 28. 01. 2026, 10:26:08 »

nechali ai pocitac na pospas, tak se o nej stara a bloguje.

https://posledniping.cz/

:-DDDDDDD von je boží...
Teda mám pocit že se dost opakuje, ta témata jsou den za dnem dokolečka. Ale...  :-D

2

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

« kdy: 28. 01. 2026, 07:18:33 »

There is new cool kid in the town - Clawdbot. Instaluje se to lokalne, defaultne pouziva lokalni LLM, ...

S lokálně běžícím LLM, byť přednaučeným, dokázal tohle všechno? :-O
V tom případě: "panenko skákavá".

3

Hardware / Re:Výber UPS k PC domov

« kdy: 14. 01. 2026, 17:41:33 »

...Obyčejný prašivý elyt je do 85°C - toto nebrat.

On nejakou dobu taky prezije, a kdyz mu zaridis nejaky ofuk, tak je vpohode.

Hodně záleží na okolnostech. V jakém je to obvodu a jaký proud to musí snášet. Výrobci měničů obvykle kondíkům nenechávají rezervu v zatížitelnosti střídavým proudem. Rozdíl "obyčejný vlhký elyt vs. low-ESR vlhký elyt" bývá běžně dvojnásobek. Low-ESR elyt na 85°C jsem asi ještě nepotkal. Proto se s 85°C sortimentem pro použití ve spínaných napájecích zdrojích už ani nezdržuju.

To ze soudruzi dizajneri dizajnujou veci tak aby byly co nejmensi a idealne jeste nacpany do uzavreny krabice bez chlazeni je samo druha vec.

V tomto bodě se 100% shodneme :-)

Videl sem treba takhle opravovany monitory/tv ... kde dotycny proste vyriz do tech plastu diru a dal tam 120/140mm vetrak ... a celej problem s prehrivanim (a odchazenim kondiku) byl vyresen.

Kdybyste nenapsal, že se jednalo o monitory/TV, tak bych Vám odpověděl, že jsem v tom asi měl prsty :-D

4

Hardware / Re:Výber UPS k PC domov

« kdy: 13. 01. 2026, 15:08:01 »

Hlavně si tam dát kondíky na vyšší teplotu, zejména, pokud jsou u nějakých chladičů. Vyšší napětí nevadí, ale bývají fyzicky větší, takže už se nemusí vejít.

Taktak, jiné než na 105°C vůbec neuvažuju. Elyty na teplotu vyšší než 105°C se dělají taky, viděl jsem tuším 125 nebo 135°C. Ale je to exotický sortiment pro automotive použití, výběr je opravdu hubený a dostupnost bídná. 105°C je klasika pro spínané měniče. Obyčejný prašivý elyt je do 85°C - toto nebrat.

...v této souvislosti, solid polymer se nenafoukne a nevyteče. Jasně, pokud ho ženete přes hranu, tak se taky přehřeje a jde do zkratu nebo exploduje - ale pokud mu naložíte míň než je jeho maximum, tak jsem vadný kus ještě neviděl. Zejména v obvodech, kde jsem polymerem nahradil vlhký elyt.
Například vyhazuju deset-patnáct let staré levné switche, kde jsem tohle provedl, protože na dnešní dobu zbytečně žerou a jejich firmware morálně zaostává.

5

Hardware / Re:Výber UPS k PC domov

« kdy: 13. 01. 2026, 14:47:47 »

Hlavně si tam dát kondíky na vyšší teplotu, zejména, pokud jsou u nějakých chladičů. Vyšší napětí nevadí, ale bývají fyzicky větší, takže už se nemusí vejít.

Taktak, jiné než na 105°C vůbec neuvažuju. Elyty na teplotu vyšší než 105°C se dělají taky, viděl jsem tuším 125 nebo 135°C. Ale je to exotický sortiment pro automotive použití, výběr je opravdu hubený a dostupnost bídná. 105°C je klasika pro spínané měniče. Obyčejný prašivý elyt je do 85°C - toto nebrat.

6

Hardware / Re:Výber UPS k PC domov

« kdy: 13. 01. 2026, 10:29:33 »

2 ks 2200 mikroF 50V
1 ks 1000 mikroF 35V
1 ks 1000 mikroF 25V
1 ks 1000 mikroF 16V

2200 uF / 50V :
https://www.tme.eu/cz/details/upw1h222mhd/elektrolyticke-kondenzatory-tht/nichicon/

1000 uF / 35V :
https://www.tme.eu/cz/details/eeufr1v102/elektrolyticke-kondenzatory-tht/panasonic/

1000 uF / 25V, dva bráchové o stejném průměru 10 mm, ten delší má o fous větší povolený proud (ostatně mrkněte do datasheetu):
https://www.tme.eu/cz/details/eeufr1e102/elektrolyticke-kondenzatory-tht/panasonic/
https://www.tme.eu/cz/details/eeufr1e102l/elektrolyticke-kondenzatory-tht/panasonic/
Na 25V je 1000 uF ještě dost vysoká kapacita. Pokud má UPSka velké železné trafo, tzn. běží na 50 Hz, tak o kapacitu jde. Pokud UPSka obsahuje VF měnič, tak tam půjde daleko spíš o ESR a volil bych solid polymer i za cenu nižší jmenovité kapacity - protože polymer bude mít dvojnásobný povolený proud.

1000 uF / 16V:
Nejprve dva vlhké elyty, opět dva bráchové o různých rozměrech. Kupodivu snesou menší proud, než modely na 25V (které jsou ovšem rozměrnější) a z těchto dvou druhý jmenovaný = štíhlejší snese míň.
https://www.tme.eu/cz/details/eeufr1c102b/elektrolyticke-kondenzatory-tht/panasonic/
https://www.tme.eu/cz/details/eeufr1c102l/elektrolyticke-kondenzatory-tht/panasonic/
Dají se koupit taky polymerní kousky, např. tenhle má 13 mOhmů, údaj o povoleném proudu 5.2 A najdete v datasheetu:
https://www.tme.eu/cz/details/a750ms108m1caae013/polymerove-kondenzatory-tht/kemet/

Zmíněné modely vlhkých elytů (Panasonic FR, Nichicon PW) jsou low-ESR modely. Zejména FR se parametry blíží solid polymerům. Pravda je, že low-esr elyty nejsou úplně nejmenší. Dají se najít kondíky v menších rozměrech, ale budou mít vyšší ESR a tedy také nižší povolený proud, tzn. za jinak stejných okolností kratší životnost...
"Obyčejné" elyty mají oproti low-ESR modelům klidně násobně vyšší odpor a tedy nižší povolený proud. Omezením je vnitřní ohřev kondíku protékajícím proudem, jde o chlazení (rozptyl tepla). Když kondíku moc naložíte, bude se hřát a ztratí životnost.

Taky bývalo módou, vlhké elyty paušálně dvojnásobně předimenzovat co do jmenovitého napětí - kvůli životnosti. Mám určité podezření, že tahle pranostika vznikla spíš tak, že v určité době v určitém rozpětí kapacit (na motherboardech okolo CPU VRM) vycházely konkrétní modely levných řad kondíků pro vyšší napětí lépe taky co do povoleného proudu a reálné životnosti... netuším zda to lze zobecňovat. Je třeba jít do datasheetů a porovnávat konkrétní kandidáty. Osazovat 50V koďan na pozici, kde reálně ponese 24V, samozřejmě znamená také větší rozměry. Samozřejmě totéž platí o nižších napěťových hladinách. A od cca 12V níž se dají jako náhrada důstojně použít solid polymery, a tyto stačí dimenzovat na "nejblíže vyšší" jmenovitou hladinu (oproti reálnému napětí). Často to pak vyjde dobře i rozměrově, aniž by se musela škrtit kapacita.

7

Hardware / Re:Výber UPS k PC domov

« kdy: 10. 01. 2026, 11:32:18 »

"Eaton Ellipse Eco 650 USB FR"

Zapomněl jsem dodat: bacha má tuším taky ségru bez USB. S tou by nefungoval automatický graceful shutdown počítače.

8

Hardware / Re:Výber UPS k PC domov

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

Baterky: standardní UPSková baterka je 7 nebo 7,2 Ah. Zcela běžně se řadí do série. Kdysi jsem viděl asi 40kW UPS, kde byly série dlouhé asi 400V. Jinde mám starou rackovou APC SmartUPS, ve které mám tyhle baterky 2x2=4 (dva sériové řetězy po 2 kusech, spojené natvrdo paralelně).
Konkrétně bych zmínil značku Yuasa - kvalita podobná jako Panasonic, ale menší příplatek za značku. Opakovaně kupuju Yuasa NP7-12 a nikdy mi nevydržely míň jak 5 let. Když kupujete náhradní baterky, pozor na dvě velikost faston vývodů: tuším 6.3 vs. 4.8 mm. Yuasa NP7-12 má 4.8, NP7-12L má 6.3.

EATON UPS 9E 1000i Rack 2U má 80mm ventilátor a dělá randál jako prase.
Přitom fouká studený vzduch, a krásný chladící tunel uvnitř (na tranzistorech) je studený.
Ventilátor se dá nahradit pomalejším a tišším, aniž by to objektivně vadilo chlazení - ale ventilátor má čidlo otáček, a když dáte citelně slabší náhradu (která objektivně zcela stačí) tak firmware držkuje že vadný ventilátor :-( Za mě to je naschvál kurvítko, aby zákoši brali dražší modely UPS se spojitou regulací otáček.

Taky mám u jednoho samostatného toweru "Eaton Ellipse Eco 650 USB FR". Mám ji chvilku, baterka je zatím původní, jenom jsem se podíval dovnitř hned když byla nová (sem byl zvědavej no).
Konstrukčně je to ohavný plasťák. Měnič je vysokofrekvenční = žádné těžké 50Hz trafo.
Ohledně součástkové základny si nedělám iluze.
Nemá ventilátor = je tichá.
"FR" = francouzské zásuvky.
Má USB port, dá se v Linuxu opracovat open-source softwarem NUT, driver usbhid-ups . Asi bych někde vyštrachal i konfigurák...  pro Windows má tuším Eaton svůj software.

Obecně výdrž UPSky je daná hlavně kapacitou baterky. Krát drobné rozdíly v účinnosti. Standardní UPSková gelovka má jmenovitých 12V / 7 Ah. Ve větších UPSkách je jich několik kusů.
Na příslušný výkon a pár minut času bývá bohužel spočítané i chlazení offline UPSek - takže připojit baterku z traktoru je riziko, že to měnič nedá tepelně (v režimu "záloha aktivní"). UPSky s dvojitou konverzí by to měly dávat v klidu.

Ohledně kondíků... u levných modelů UPS určitě tlačí výrobce na cenu, takže tam budou čínské elyty. Obecně v některých zařízeních je měním preventivně :-) V dnešních konstrukcích jich naštěstí už není tolik (kusů) protože menší kapacity se řeší keramikou. Bohužel každý model hardwaru obdahuje jinou sadu kondíků, takže výměna znamená zařízení rozebrat, zjistit hodnoty a počty původních součástek (případně i změřit skutečná napětí, na nízkovoltových větvích) a pak vybrat něco v TME. Na primár něco od značek Nichicon / Panasonic - volit modely s rozsahem do 105°C a pokud možno low ESR. Na sekundár / malé napětí buď Panasonic FR elyt nebo jakýkoli solid polymer, pokud dává smysl kombinací napětí a kapacity.

9

Windows a jiné systémy / Re:Skok systémového času Windows

« kdy: 09. 01. 2026, 17:59:20 »

Gratuluji k vyřešení, a děkuji za zajímavý dotaz.

Přestože teď máte hypervizor už zasynchronizovaný, doporučuji ponechat guestům aktivní pouze jeden způsob synchronizace: w32time, nebo VMware Tools, nebo nějaký další. Pokud necháte aktivní dva nebo více způsobů synchronizace uvnitř jednotlivého guesta, zvyšuje se riziko "zvláštních efektů" (houpání zpětnovazební smyčky dolaďování frekvence apod.)

Mimochodem, ohledně přechodů zimní/letní čas... UNIX jede interně UTC, Windows podle mého taky. Časová zóna a střídání zimního/letního času je za běhu záležitostí prezentace v uživatelském rozhraní (s podporou systému).
Doporučil bych nastavit vindózům ve VM, ať si čas do emulovaného RTC ukládají v UTC (především bez střídání letního a zimního času). Pak by Vám měly odpadnout skokové změny, pokud guest VM změnu času "prospal" ve vypnutém stavu.

Zdá se, že emulovaný RTC (jak ho vidí guest VM) umí uložit aktuální čas guesta - ovšem neukládá ho jako absolutní čas, ale jako offset oproti času hostitele=hypervizoru. Emulovaný RTC proto při vypnutém guestovi nedriftuje, "tiká pořád přesně". Ofset emulovaného RTC lze snad také nastavit explicitně, per guest...
Ohledně chování emulovaného RTC ve VMware najde Google jenom letité PDFko (kapitola "Virtual CMOS RTC" na str.7). Meinbergové mluví také o VMware knowledge-base záznamu na téma timekeeping - netuším, jestli je to dnes k dispozici jenom po přihlášení / v rámci placeného supportu nebo jak.

10

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

« kdy: 08. 01. 2026, 23:06:01 »

Opět jedna aktualita o "modelech mimo dnešní mainstream": šéfová z firmy/teamu Pathway vypráví (poněkud povrchně) o jejich "reasoning modelu": zmiňuje kontinuální učení, "neurons that fire together wire together", postupné spontánní rozšiřování sítě, "bezměřítkový model"...

11

Windows a jiné systémy / Re:Divné chování sítě ve Win 11 v Proxmoxu

« kdy: 07. 01. 2026, 16:38:48 »

Mně občas Windows 10 / 11 na holém železe dělají malé sabotáže síťové konektivity ve chvíli, kdy chtějí restart kvůli aktualizaci. Což chtějí v některých rušnějších obdobích prakticky ob den.

Ještě mě napadá... je legální, provozovat tyhle stolní windows v "serverové virtualizaci" ? Pokud se nad tím nápadem mračí licenční podmínky, jestli to není i nějak technicky podpořeno...

Mimochodem si v tom Proxmoxu nainstalujte tcpdump, a uvidíte, odkud kam co chodí. Pokud máte VLAN-aware vmbr0, tak můžete zkusit poslouchat na něm, nebo na vnějším fyzickém rozhraní Proxmoxu, nebo na TAP rozhraní konkrétního běžícího guesta... Na fyzickém venkovním rozhraní byste měl vidět i VLAN tagy, pokud na něm VLANy tagujete.

tcpdump -e -n -i eth0
tcpdump -e -n -i eth0 host 10.1.2.3
tcpdump -e -n -i eth0 ether host 00:02:3b:4c:30:21

12

Windows a jiné systémy / Re:Skok systémového času Windows

« kdy: 07. 01. 2026, 16:17:40 »

Já myslím, že jste na správné cestě. Vlastně píšu jenom abych přidal dva odkazy na související čtení v Meinbergovic knowledgebase, ohledně VMware:
[1]
[2]
Ale v podstatě se tam k tématu této debaty už nedočtete nic moc nového... nad rámec těch pár bodů, které už tu zmínili předřečníci.
(Upozornění na lehký střet zájmů: značka Meinberg mě živí.)

13

Windows a jiné systémy / Re:Skok systémového času Windows

« kdy: 07. 01. 2026, 13:07:48 »

Na Windows (uvnitř QEMU+KVM) používám tohle, mohlo by pomoci. https://www.timesynctool.com/

1.) proti gustu žádný dišputát. Pokud Vám to funguje, klidně si poslužte...

2.) nemá specifickou podporu pro virtuální časoměrná zařízení hypervizoru QEMU+KVM (ani pro VMware)

3.) pokud to použijete, vypněte všechny ostatní způsoby dolaďování času ve VM guestovi = zastavte standardní MS servisku w32time, VMware tools, cokoli dalšího případně sahá na systémový čas

4.) ta věc je zcela banální SNTP klient, původně vyvinutý pro Win98. Tzn. patrně umí reálně méně, než standardní NTčkový w32time, a velmi pravděpodobně méně, než třeba Win32 build ntpd (nějaký binární build mají k dispozici Meinbergové, ale viděl jsem alternativní build i od někoho dalšího).
Ale ten Váš timesynctool bude také citelně méně složitý na konfiguraci, než zmíněné "seriózní" servisky.

14

Windows a jiné systémy / Re:Skok systémového času Windows

« kdy: 07. 01. 2026, 12:57:33 »

Nedočetl jsem se důležitou informaci: máte důvod se domnívat, že ten VMware (hypervizor) má správný čas?
Díval jste se? Bere si ho odněkud přes NTP?

Dál bych zkoumal, zda nemám náhodou povolené dva (či více) mechanismy, aby mi konfigurovaly čas v guest-side OS.
Servisky dolaďující čas toto obvykle činí dolaďováním rychlosti běhu (="frekvence") softwarové časové základny. Pokud se začnou dvě různé zpětnovazební smyčky "pravidelně přetahovat o kormidlo", můžou být výsledky zajímavé.
Nebo jedna smyčka dolaďuje frekvenci, a druhý kousek softwaru dolaďuje periodicky skokem na chybný čas...
Doladění skokem je z hlediska best practices v oboru časomíry nešťastné řešení, ale při velkém rozdílu asi jediné správné.

Tzn. zatím by se hypoteticky mohlo jednat o soupeření mezi nativní MS serviskou w32time (která může brát buď NTP, nebo páchá zmíněný "Secure Time Seeding" ze SSL), vs. VMware Tools.
Kromě toho si guest OS při startu bere čas z emulovaného RTC, jak už tu správně psal Filip Jirsák.
Vrtá mi hlavou, jestli Vám tam běží nějaký další nespecifikovaný software, zda se třeba nesnaží ještě taky po svém zasahovat do systémového času - to už je na Vás.
Dále, pokud by se stalo, že daný VM guest je v nějakých časových periodách držen hodně zkrátka co do přístupu ke strojovému času hostitelova CPU, takže mu softwarová časová základna běží pomaleji, než si třeba v lepších časech nakalibroval, velmi teoreticky by to taky mohlo vést k následným skokovým korekcím...

Neznám VMware. Třeba KVM+QEMU umí guestovi exportovat emulované fyzické hodiny "PHC", pro které je tuším guest-side virtio ovladač. Následně linuxový guest umí toto "autoritativní PHC" využít k doladění své softwarové časové základny, asi by podle toho uměl běžet i ntpd v guestově OS apod. Windows jsou v této oblasti za linuxovým světem vývojově pozadu, ale postupně to zaostávání dotahují. Nedávno přibyla podpora PTP (konkrétní profile), tuším i zárodek podpory pro HW timestamping v síťových kartách, nevím jak obecnější podpora PHC.

15

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

« kdy: 06. 01. 2026, 21:34:53 »

Ještě jeden shameless plug v té mé neuro-bio lajně: dneska jsem zaslechl v rádiu tenhle rozhovor. Hostem byl neurolog Prof. Vladimír Komárek, emeritní přednosta Kliniky dětské neurologie 2 LF UK a FN Motol. Jasně, celé to bylo laděné do edutainmentové roviny pro široké publikum, přesto tam padlo pár poznámek, ke kterým by mě zajímaly odkazy na zdroje / další detailnější čtení. Konkrétně co všechno už vědecká obec dokázala zjistit. Jenom letmo naznačená témata:
- známe význam některých konkrétních genů (pro vývoj mozku prentální i post-natální, a pro jeho poruchy)
- zmínil, že na moderním FMRI lze přibližně identifikovat množinu drah zodpovědných za základní "proud vědomí"
- různé "druhy" epilepsie = různé mechanismy její emergence
- zmínil hypotézu o "mikrotubulách" (nevím jestli v synapsích nebo dendritech) = možnost, že uvnitř synapsí a snad cytoplazmy neuronu existuje detailnější struktura, která se chová jako paralelní komunikační sběrnice (nevím zda hypotéza tvrdí i něco o funkci zpracování takto proudících dat) - o tomhle nápadu jsem četl před pár lety, ale nevím o tom, že by se s tím někam pohnuli.
...a další.
Zmiňoval třeba taky myší hippocampus a place-map neurony = je to další člověk, který to na myších zkoumal, tady v ČR.