Byla vydána verze 1.67.0 programovacího jazyka Rust (Wikipedie). Podrobnosti v poznámkách k vydání. Vyzkoušet Rust lze například na stránce Rust by Example.
Byla vydána nová verze 23.1 open source firewallové a routovací platformy OPNsense (Wikipedie). Jedná se o fork pfSense od této verze postavený na FreeBSD místo HardenedBSD. Kódový název OPNsense 23.1 je Quintessential Quail. Přehled novinek v příspěvku na blogu.
Sdružení CZ.NIC, správce české národní domény, zveřejnilo Domain Report 2022, ve kterém upozorňuje na zajímavá data spojená s doménou .CZ. Na konci roku 2022 bylo evidováno celkem 1 463 116 domén. Průměrně bylo měsíčně zaregistrováno 17 193 domén, přičemž nejvíce registrací proběhlo v listopadu (23 581) a nejméně pak v červenci (13 199). Na rozdíl od předchozích let byl poprvé v historii zaznamenán propad v počtu domén zabezpečených
… více »Infisical je open source nástroj s end-to-end šifrováním pro snadnou správu a synchronizaci proměnných prostředí (.env souborů) napříč vývojovým týmem, zařízeními a infrastrukturou. Zdrojové kódy jsou k dispozici na GitHubu.
Interaktivní rozšiřovatelný editor pro práci se strukturovanými binárním daty GNU poke byl vydán v nové major verzi 3.0. Přehled novinek v poznámkách k vydání.
Kosťa Šiškov v posledních několika týdnech na svém blogu vzpomínal na různé přispěvatele do projektu FFmpeg: konec forku Libav, úvod, …, shrnutí.
Byla vydána nová verze 3.7 frameworku Flutter (Wikipedie) pro vývoj mobilních, webových i desktopových aplikací a nová verze 2.19 souvisejícího programovacího jazyka Dart (Wikipedie).
Wine 8.0 bylo vydáno. Přehled novinek v poznámkách k vydání. Tato verze dokončuje přechod na Portable Executable moduly a WoW64 (volání 64bitových knihoven ze 32bitových aplikací).
Jon Masters znovu oživil Linux Kernel Podcast, ve kterém shrnuje dění v e-mailových konferencích vývojářů jádra Linux za uplynulý týden. První díl nové řady (přepis) vyšel 21. ledna. Neslibuje ale vydání podle pevného harmonogramu. Podcast dříve vydával v letech 2009 a 2017.
Byla vydána nová verze 5.9 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Přehled změn v příslušném seznamu.
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á.