Nevidomý uživatel Linuxu v blogu upozornil na tristní stav přístupnosti na linuxovém desktopu (část první, druhá, závěr), přičemž stížnosti jsou podobné jako v roce 2022. Vyvolal bouřlivou odezvu. Následně např. Georges Stavracas shrnul situaci v GNOME. Debata o jiném aspektu přístupnosti, emulaci vstupu pod Waylandem, také proběhla na Redditu.
DevConf.CZ 2025, tj. open source komunitní konference sponzorovaná společností Red Hat, proběhne od 12. do 14. června v Brně na FIT VUT. Publikován byl program a spuštěna byla registrace.
Byla vydána nová major verze 28.0 programovacího jazyka Erlang (Wikipedie) a související platformy OTP (Open Telecom Platform, Wikipedie). Přehled novinek v příspěvku na blogu.
Český telekomunikační úřad zveřejnil Výroční zprávu za rok 2024 (pdf), kde shrnuje své aktivity v loňském roce a přináší i základní popis situace na trhu. Celkový objem přenesených mobilních dat za rok 2024 dosáhl dle odhadu hodnoty přibližně 1,73 tis. PB a jeho meziroční nárůst činí zhruba 30 %. Průměrná měsíční spotřeba dat na datovou SIM kartu odhadem dosáhla 12,5 GB – v předchozím roce šlo o 9,8 GB.
Z novinek představených na Google I/O 2025: Přehledy od AI (AI Overviews) se rozšiřují do dalších zemí. Užitečné, syntetizované přehledy od generativní AI jsou nově k dispozici i českým uživatelům Vyhledávače.
Šestice firem označovaných jako „MAMAAN“ – tedy Meta (Facebook, Instagram), Alphabet (Google), Microsoft, Apple, Amazon a Netflix – je zodpovědná za více než padesát procent světového internetového provozu. Dalšími velkými hráči jsou TikTok a Disney+. Společně tak zásadně určují podobu digitálního prostředí, spotřebitelského chování i budoucích trendů v oblasti technologií. I přesto, že se podíl těchto gigantů od roku 2023 o něco snížil, jejich dominantní postavení zvyšuje volání po regulaci.
Evropská komise (EK) navrhuje zavést plošný poplatek ve výši dvou eur (zhruba 50 Kč) za každý malý balík vstupující do Evropské unie. Poplatek se má týkat balíků v hodnotě do 150 eur (zhruba 3700 Kč), které v EU nepodléhají clu. V loňském roce bylo do EU doručeno kolem 4,6 miliardy takovýchto balíků. Poplatek má krýt náklady na kontroly rostoucího počtu zásilek levného zboží, které pochází především z Číny.
Dnes a zítra probíhá vývojářská konference Google I/O 2025. Sledovat lze na YouTube a na síti 𝕏 (#GoogleIO).
V Bostonu probíhá konference Red Hat Summit 2025. Vybrané přednášky lze sledovat na YouTube. Dění lze sledovat na síti 𝕏 (#RHSummit).
Společnost Red Hat oficiálně oznámila vydání Red Hat Enterprise Linuxu 10. Vedle nových vlastností přináší také aktualizaci ovladačů a předběžné ukázky budoucích technologií. Podrobnosti v poznámkách k vydání.
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
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