Byla vydána nová stabilní verze 24.05 linuxové distribuce NixOS (Wikipedie). Její kódové označení je Uakari. Podrobný přehled novinek v poznámkách k vydání. O balíčky se v NixOS stará správce balíčků Nix.
Byla vydána nová verze 1.48.0 sady nástrojů pro správu síťových připojení NetworkManager. Novinkám se v příspěvku na blogu NetworkManageru věnuje Fernando F. Mancera. Mimo jiné se v nastavení místo mac-address-blacklist nově používá mac-address-denylist.
Před 25 lety, 31. května 1999, započal vývoj grafického editoru Krita (Wikipedie). Tenkrát ještě pod názvem KImageShop a později pod názvem Krayon.
Farid Abdelnour se v příspěvku na blogu rozepsal o novinkám v nejnovější verzi 24.05.0 editoru videa Kdenlive (Wikipedie). Ke stažení brzy také na Flathubu.
David Revoy, autor mj. komiksu Pepper&Carrot, se rozepsal o své aktuální grafické pracovní stanici: Debian 12 Bookworm, okenní systém X11, KDE Plasma 5.27, …
Wayland (Wikipedie) byl vydán ve verzi 1.23.0. Z novinek lze vypíchnout podporu OpenBSD.
Craig Loewen na blogu Microsoftu představil novinky ve Windows Subsystému pro Linux (WSL). Vypíchnout lze GUI aplikaci pro nastavování WSL nebo správu WSL z Dev Home.
V sobotu 1. června lze navštívit Maker Faire Ostrava, festival plný workshopů, interaktivních činností a především nadšených a zvídavých lidí.
Webový server Caddy (Wikipedie) s celou řadou zajímavých vlastností byl vydán ve verzi 2.8 (𝕏). Přehled novinek na GitHubu.
Byla vydána verze 3.0 (@, 𝕏) svobodného softwaru HAProxy (The Reliable, High Performance TCP/HTTP Load Balancer; Wikipedie) řešícího vysokou dostupnost, vyvažování zátěže a reverzní proxy. Detailní přehled novinek v příspěvku na blogu společnosti HAProxy Technologies.
Pracujem na jednom projekte, v ktorom sa spúšťa jeden malý program veľký počet krát (rádovo stovky) a pri každom spustení potrebuje vygenerovať unikátne meno výstupného súboru a odovzdať ho inému procesu. Utilitka môže bežať na viacerých klientoch naraz a výstupný súbor bude vznikať na serveri v čase, keď už utilitka nebeží.
Čo s tým? Jednoduché. Meno sa generuje podľa aktuálneho času s presnosťou na milisekundu, prihodí sa meno klienta, celé sa to zabalí do mutexu a v mutexe sa počká dlhšie ako 1ms. Akurát, že to nefunguje. Teda väčšinou to funguje. Na mojom stroji je to OK. Na testovacom stroji 700 km ďaleko tiež. Ale na nejakom stroji kdesi v XY v necelom percente pripadov to vygeneruje opakujuci sa identifikator.
Záhada.
Tu je kód:
void UniqueName(char *buffer)
{
struct timeval tv;
sem_t *mutex=NULL;
char hostname[100];
if (!gethostname(hostname,sizeof(hostname)))
{
mutex=sem_open("MyMutex",O_CREAT,0700,1);
if (mutex!=SEM_FAILED)
{
sem_wait(mutex);
gettimeofday(&tv,NULL);
sprintf(buffer,"%s-%d-%d\n",hostname,tv.tv_sec,tv.tv_usec);
usleep(5000);
sem_post(mutex);
sem_close(mutex);
}
else
perror("sem_open");
}
}
Pôvodný kód je na Win32, takže som sa povŕtal v tom, ako sa to robi na Linuxe. Treba mať jadro 2.6, glibc s NPTL, bežiaci udev a permission na /dev/shm. V originále sú ošetrené všetky systémové volania a žiadne nezlyhá.
No a pointa? Mám teóriu, prečo ten kód zlyháva. A je taká bláznivá, že som chcel počuť najprv nápady od vás. Tak čo si myslíte?
Tiskni Sdílej:
Utilitka môže bežať na viacerých klientoch naraz a výstupný súbor bude vznikať na serveri v čase, keď už utilitka nebeží.Aha, to jsem prve pochopil špatně. Teď už to nechápu vůbec. Jméno generuješ na klientech?
To by som tú pamäť musel zdieľať medzi viacerými strojmi v sieti.To přece ne, stačí, když ty klienty očísluješ. Čísla jim buď může přiřazovat server nebo jde-li o uzavřený systém, tak je můžeš očíslovat předem.
Ale na nejakom stroji kdesi v XY v necelom percente pripadov to vygeneruje opakujuci sa identifikator.A nebeží na tom stroji náhodou nejaký démon na synchronizáciu času alebo niečo také?
Stavite na predpokladech, ze
A obecne spat v kriticke sekci je opravdu zavrzenihodne.
> Kazdy stroj ma jedinecny hostname To je, podľa mňa, celkom pravdivý predpoklad. Keby neplatil, tak by to spôsobovalo kadejaké iné problémy, ktoré by sa prejavili skôr. Môžem mať v NT doméne dva stroje s rovnakým hostname?Stroj moze mat iny hostname a iny zaznam v dns (inac sa vidi on sam a inac ho vidia ostatne stroje).
Cas na na kazdem stroji bezi jednim smeremTento predpoklad je skutočne mylný, pretože ten stroj, kde problém vzniká si synchronizuje čas (čo je defaultne vypnuté) a mňa to jednoducho nenapadlo.
Rozumne implementace synchronizatoru casu meni cas postupnym spomalovanim nebo zrychlovanim a to na urovni jadra, takze by se cas nemel vracet zpet. (Tj. spoustet kazdou hodinu ntpdate je spatne, ale nechat bezet ntpd je dobre.)
usleep() se muze ovlivnovat s jinymi funkcemi, napr. s alarm()emTo je pravda, ale o tom, že dôjde k alarm()-u, by som sa dozvedel z toho, že sa urobí jeho obsluha.
Nejde jen o alarm(), tech nebezpecnych funkci je mnohem vice. Ale predpokladam, ze vite, co delate.
Rozumne implementace synchronizatoru casu meni cas postupnym spomalovanim nebo zrychlovanim a to na urovni jadra, takze by se cas nemel vracet zpet. (Tj. spoustet kazdou hodinu ntpdate je spatne, ale nechat bezet ntpd je dobre.)Což platí jen v případě, že je čas posunutý jen málo. Pokud se čas od přesného času liší třeba o několik dní, není možné jej synchronizovat tak, že několik týdnů poběží hodiny rychleji/pomaleji.
jak moc se mi ty hodiny v HW vlastne predbihaji?Některé dost Problém je, že ntpdate při bootu nemusí čas sesynchronizovat vždy správně (např. během bootu není dostupný internet, třeba i jen z toho důvodu, že po výpadku proudu nabootuje router později, než ntpdate na jiném PC). A navíc
ntpd
nemá moc rádo výpadky internetu – dokáže v takovém případě přestat synchronizovat čas, ale démon běží dál, takže na první pohled nic nepoznáte. Jednou mi tahle kombinace způsobila to, že na serveru, který s ejinak normálně synchronizoval, běžel démon ntpd
, ale čas byl posunut o několik měsíců…
while ! (ntpdate ser.ver); do true; done
dd if=/dev/urandom bs=256 count=1 2>/dev/null | md5sum --binary| cut -d ' ' -f 1