Byla publikována Výroční zpráva Blender Foundation za rok 2024 (pdf).
Byl vydán Mozilla Firefox 143.0. Přehled novinek v poznámkách k vydání a poznámkách k vydání pro vývojáře. Nově se Firefox při ukončování anonymního režimu zeptá, zda chcete smazat stažené soubory. Dialog pro povolení přístupu ke kameře zobrazuje náhled. Obzvláště užitečné při přepínání mezi více kamerami. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 143 bude brzy k dispozici také na Flathubu a Snapcraftu.
Byla vydána betaverze Fedora Linuxu 43 (ChangeSet), tj. poslední zastávka před vydáním finální verze, která je naplánována na úterý 21. října.
Multiplatformní emulátor terminálu Ghostty byl vydán ve verzi 1.2 (𝕏, Mastodon). Přehled novinek, vylepšení a nových efektů v poznámkách k vydání.
Byla vydána nová verze 4.5 (𝕏, Bluesky, Mastodon) multiplatformního open source herního enginu Godot (Wikipedie, GitHub). Přehled novinek i s náhledy v příspěvku na blogu.
Byla vydána verze 3.0 (Mastodon) nástroje pro záznam a sdílení terminálových sezení asciinema (GitHub). S novou verzí formátu záznamu asciicast v3, podporou live streamingu a především kompletním přepisem z Pythonu do Rustu.
Canonical oznámil, že bude podporovat a distribuovat toolkit NVIDIA CUDA (Wikipedie) v Ubuntu.
Tržní hodnota americké společnosti Alphabet, která je majitelem internetového vyhledávače Google, dnes poprvé překonala hranici tří bilionů dolarů (62,1 bilionu Kč). Alphabet se připojil k malé skupině společností, které tuto hranici pokořily. Jsou mezi nimi zatím americké firmy Nvidia, Microsoft a Apple.
Spojené státy a Čína dosáhly dohody ohledně pokračování populární čínské platformy pro sdílení krátkých videí TikTok v USA. V příspěvku na síti Truth Social to dnes naznačil americký prezident Donald Trump. Dosažení rámcové dohody o TikToku vzápětí oznámil americký ministr financí Scott Bessent, který v Madridu jedná s čínskými představiteli o vzájemných obchodních vztazích mezi USA a Čínou. Bessentova slova později potvrdila také čínská strana.
MKVToolNix, tj. sada nástrojů pro práci s formátem (medialnym kontajnerom) Matroska, byl vydán ve verzi 95.0. Podpora přehrávání formátu Matroska míří do Firefoxu [Bug 1422891, Technický popis]. Přehrávání lze již testovat ve Firefoxu Nightly.
Tento mail v linux-kernel mailing listu mě přivedl k zamyšlení, jak se s tím, jak Linux postupně získává další a čím dál lepší schopnosti, zároveň zvyšují očekávání, která od něj lidé mají:
Hello! I need use sleep with accurat timing. I use 2.6.21 with rt-prempt patch. with enabled rt_preempt, dyn_ticks, and local_apic But req.tv_nsec = 300000; req.tv_sec = 0; nanosleep(&req,NULL) make pause around 310-330 microseconds. I tried to understend how work nanosleep(), but it not depends from jiffies and from smp_apic_timer_interrupt. When can accuracy be lost? And how are process waked up? GolovaSteek
Ještě úplně nedávno (předtím, než Linux dostal časovače s vysokým rozlišením) když nějaký proces požádal o dočasné uspání na krátkou dobu, Linux ho nemohl probudit dřív než za jednu jiffy, tj. jeden celý tik časovače. Při obvyklém nastavení HZ=1000 to byla tedy vždy aspoň jedna milisekunda navíc k požadované době uspání. Při HZ=100 by to bylo deset milisekund.
Dneska se lidi diví, že když požádají o prodlevu 300 mikrosekund, bude ve skutečnosti delší o 10 až 30 mikrosekund a ještě jim ten 20-mikrosekundový nepředvídatelný jitter vadí.
To bych teda rád věděl, jaká aplikace má takové přísné požadavky, a proč si vůbec někdo myslí, že je PCčko může být schopno splnit.
Linux je v tomto případě totiž už tak skvělý, že možnosti programu jsou omezovány převážně schopnostmi hardwaru.
Tiskni
Sdílej:
Jaký je vůbec praktický rozdíl meze linuxem a unixem? Zjistil jsem, že v jednom železe žijí vxworks, v něčem sakra stabilním. Takže nějaké řešení, východisko, být musí.
Co je tam za řízení? To snad je jen statistika (+-), pustit do sebe dva svazky, změřit, vyhodnotit, najít nové částice ... ?
Nicméně na takové řízení se asi používají opravdu ty jednočipy.Dnešní trend (který se mi příliš nelíbí, ale co nadělám) je ovšem soustřeďovat co nejvíc činností do jediného fyzického počítače. S tím, že jednotlivé funkce (u toho auta třeba řízení motoru, bezpečnostní systémy, diagnostika, klimatizace, rádio/TV atd.) běží v oddělených kontejnerech uvnitř nějakého hard real-time systému (např. PikeOS). Ty skutečně kritické aplikace (motor, bezpečnost) jsou přímo v podobě nativních programů v jednotlivých kontejnerech, méně kritické pak mohou běžet na normálním OS (třeba Linuxu) nebo VM (třeba JVM) v rámci dalších kontejnerů.
Pokud myslíte stroj ve smyslu fyzického zařízení, které s něčím hýbe, tak shodně s vámi nenalézám nic, kde je timing s rozlišením 10 mikrosekund nezbytný. Jedním dechem ale dodávám, že nepochybuji o existenci aplikací, které takovou přesnost vyžadují, akorát teď zrovna mě žádná nenapadá... BTW, raketoplány a jaderné reaktory jsou pomalé věci, tam nemáte kam spěchat. Ale co třeba nějaký špičkový obráběcí stroj? Jak rychle se točí hřídel a v jakých intervalech se vystavuje poloha nože?
Pokud ovšem netrváte na fyzickém pohybu věcí, pak samozřejmě existují stroje, které takovou (a ještě řádově vyšší) přesnost skutečně vyžadují. Triviálním příkladem budiž jakýkoliv gigabitový ethernetový switch - a i v těchto strojích je uvnitř nějaký CPU s nějakým OS, a i když se většina dějů takového switche odehrává "in silicon" (tedy mimo softwarový proces zpracování), některé přeci jen obsluhuje přímo CPU a musí je obsloužít pekelně rychle...
No, ja treba pouzivam casovani na urovni milisekund pro moje softwarove PWMČlánek ale mluví o mikrosekundách. To jsme trošku jinde. Přesnost v řádu miliseknud je celkém běžná a v podstatě nutná. Třeba i při přehrávání videa nebo zpracování audia posun větší než cca 10ms už člověk vnímá jako zpoždění.
Dneska se lidi diví, že když požádají o prodlevu 300 mikrosekund, bude ve skutečnosti delší o 10 až 30 mikrosekund a ještě jim ten 20-mikrosekundový nepředvídatelný jitter vadí.A proč by se sakra neměli divit? Pamatuju si jak jsem nedávno propadl záchvatu smíchu, když jsem zjistil jak blbě pre-tickless časování v Linuxu vlastně funguje. Jako diplomku jsem psal realtime plánovač pro PC-XT, a počítat timeout k nejbližšímu eventu a programovat tím PIC v one-shot módu mi přišlo jako naprostá samozřejmost. Nechápu proč Linuxu něco podobného trvalo dalších 15 let.
http://www.microsoft.com/whdc/system/CEC/mm-timer.mspx The 8254 Programmable Interval Timer (PIT) was introduced in the IBM PC in 1981. It has a resolution of 1 millisecond and supports both periodic and aperiodic modes. However, because reads from and writes to this hardware require communication through an IO port, programming it takes several cycles, which is prohibitively expensive for the OS. Because of this, the aperiodic functionality is not used in practice. For this reason, this timer is only used in periodic mode to provide the periodic clock interrupt on uni-processor systems.No, 2x IN a 2x OUT rozhodně nepovažuju za "prohibitively expensive for the OS". Navíc, wikipedia píše:
http://en.wikipedia.org/wiki/Intel_8253 In modern times, this PIT is not included as a separate chip in an x86 PC. Rather, its functionality is included as part of the motherboard's southbridge chipset. In some modern chipsets, this change may show up as measurable timing differences in accessing a PIT using the x86 I/O address space. Reads and writes to such a PIT's registers in the I/O address space may complete much faster...takže to programování PICu vůbec nemusí chodit přes nějaké pomalé emulované ISA I/O. Ad jednodušší HW: Ano, byl jednodušší. Já s jednoduchostí problém nemám, jednoduchá řešení jsou obvykle správná.