Byla vydána nová verze 19 integrovaného vývojového prostředí (IDE) Qt Creator. Podrobný přehled novinek v changelogu.
Bitwig Studio (Wikipedie) bylo vydáno ve verzi 6. Jedná se o proprietární multiplatformní (macOS, Windows, Linux) digitální pracovní stanici pro práci s audiem (DAW).
Společnost Igalia představila novou linuxovou distribuci (framework) s názvem Moonforge. Jedná se o distribuci určenou pro vestavěné systémy. Vychází z projektů Yocto a OpenEmbedded.
Google Chrome 146 byl prohlášen za stabilní. Nejnovější stabilní verze 146.0.7680.71 přináší řadu novinek z hlediska uživatelů i vývojářů. Podrobný přehled v poznámkách k vydání. Opraveno bylo 29 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
D7VK byl vydán ve verzi 1.5. Jedná se o fork DXVK implementující překlad volání Direct3D 3 (novinka), 5, 6 a 7 na Vulkan. DXVK zvládá Direct3D 8, 9, 10 a 11.
Bylo vydáno Eclipse IDE 2026-03 aneb Eclipse 4.39. Představení novinek tohoto integrovaného vývojového prostředí také na YouTube.
Ze systému Slavia pojišťovny uniklo přibližně 150 gigabajtů citlivých dat. Jedná se například o pojistné dokumenty, lékařské záznamy nebo přímou komunikaci s klienty. Za únik může chyba dodavatelské společnosti.
Sněmovna propustila do dalšího kola projednávání vládní návrh zákona o digitální ekonomice, který má přinést bezpečnější on-line prostředí. Reaguje na evropské nařízení DSA o digitálních službách a upravuje třeba pravidla pro on-line tržiště nebo sociální sítě a má i víc chránit děti.
Meta převezme sociální síť pro umělou inteligenci (AI) Moltbook. Tvůrci Moltbooku – Matt Schlicht a Ben Parr – se díky dohodě stanou součástí Meta Superintelligence Labs (MSL). Meta MSL založila s cílem sjednotit své aktivity na poli AI a vyvinout takovou umělou inteligenci, která překoná lidské schopnosti v mnoha oblastech. Fungovat by měla ne jako centralizovaný nástroj, ale jako osobní asistent pro každého uživatele.
Byla vydána betaverze Fedora Linuxu 44 (ChangeSet), tj. poslední zastávka před vydáním finální verze, která je naplánována na úterý 14. dubna.
[root@localhost ~]# ntpdate -vd 172.28.1.10
21 Nov 13:37:01 ntpdate[30685]: ntpdate 4.2.0a@1.1196-r Fri May 12 09:51:45 EDT 2006 (1)
Looking for host 172.28.1.10 and service ntp
host found : 172.28.1.10
transmit(172.28.1.10)
receive(172.28.1.10)
transmit(172.28.1.10)
receive(172.28.1.10)
transmit(172.28.1.10)
receive(172.28.1.10)
transmit(172.28.1.10)
receive(172.28.1.10)
transmit(172.28.1.10)
server 172.28.1.10, port 123
stratum 3, precision -20, leap 00, trust 000
refid [172.28.1.10], delay 0.02580, dispersion 0.00000
transmitted 4, in filter 4
reference time: caeea386.0498f5c4 Wed, Nov 21 2007 13:31:02.017
originate timestamp: caeea5e8.c4b3157a Wed, Nov 21 2007 13:41:12.768
transmit timestamp: caeea4ed.425d6beb Wed, Nov 21 2007 13:37:01.259
filter delay: 0.02582 0.02580 0.02580 0.02580
0.00000 0.00000 0.00000 0.00000
filter offset: 251.5090 251.5090 251.5090 251.5090
0.000000 0.000000 0.000000 0.000000
delay 0.02580, dispersion 0.00000
offset 251.509015
21 Nov 13:37:01 ntpdate[30685]: step time server 172.28.1.10 offset 251.509015 sec
Podle me je to takhle spravne ne? Akorat to s casem proste nehne. Nevite jaky cas ntpdate nastavuje? Systemovy nebo hwclock?
Predem dekuji za odpovedi...
ntpdate.
ntpdate a ntpd jsou fakt divné programy (ntpd se zase prozměnu nevyrovná s výpadkem spojení k časovému serveru – program běží dál, ale nesynchronizuje).
Rozhodně se tak nechovají všechny implementace ntpdate:
lion:~ # date 010101001970 ; date +%s ; ntpdate ntp.dragon.cz ; date Čt led 1 01:00:00 CET 1970 0 21 Nov 15:31:10 ntpdate[11811]: step time server 213.168.176.1 offset 1195655470.565820 sec St lis 21 15:31:10 CET 2007
Ani by to nemělo smysl - v řadě distribucí se před startem xntpd provádí jednorázová synchronizace pomocí ntpdate právě proto, aby se odstranila případná nadměrná odchylka.
Ani by to nemělo smysl - v řadě distribucí se před startemMně to smysl taky nedává, proto se pořád odmítám smířit s tím, že to takxntpdprovádí jednorázová synchronizace pomocíntpdateprávě proto, aby se odstranila případná nadměrná odchylka.
ntpdate dělá (konkrétně tato implementace).
Ten příklad, který uvádíte, u mne dopadne stejně. I mně ntpdate někdy sesynchronizuje čas správně i pokud je tam velký rozdíl. Ale pokud ntpd přestalo synchronizovat čas a následně jsem jej ukončil, odmítalo mi opakovaně ntpdate čas sesynchronizovat do té doby, než jsem čas nastavil ručně na přibližně správný čas.
ntpdate vždy čas správně sesynchronizuje. Jestli to tak bude napořád, budu jedině rád…
-B Force the time to always be slewed using the adjtime(2) system
call, even if the measured offset is greater than +-128 ms. The
default is to step the time using settimeofday(2) if the offset
is greater than +-128 ms. Note that, if the offset is much
greater than +-128 ms in this case, it can take a long time
(hours) to slew the clock to the correct value. During this
time, the host should not be used to synchronize clients.
-b Force the time to be stepped using the settimeofday(2) system
call, rather than slewed (default) using the adjtime(2) system
call. This option should be used when called from a startup file
at boot time.
(Vynate z manualu na FreeBSD 6.2.)
Nevite jaky cas ntpdate nastavuje? Systemovy nebo hwclock?
Samozřejmě systémový. Když budete předpokládat, že hwclock je jediný program, který zajímají hardwarové hodiny, nebude to sice úplně přesné, ale je to velmi dobrá aproximace.
Tiskni
Sdílej: