Byl vydán Mozilla Firefox 126.0. Přehled novinek v poznámkách k vydání, poznámkách k vydání pro firmy a na stránce věnované vývojářům. Vylepšena byla funkce "Zkopírovat odkaz bez sledovacích prvků". Přidána byla podpora zstd (Zstandard). Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 126 je již k dispozici také na Flathubu a Snapcraftu.
Grafana (Wikipedie), tj. open source nástroj pro vizualizaci různých metrik a s ní související dotazování, upozorňování a lepší porozumění, byla vydána ve verzi 11.0. Přehled novinek v aktualizované dokumentaci.
Byla vydána nová verze 24.0 linuxové distribuce Manjaro (Wikipedie). Její kódové jméno je Wynsdey. Ke stažení je v edicích GNOME, KDE PLASMA a XFCE.
Byla představena oficiální rozšiřující deska Raspberry Pi M.2 HAT+ pro připojování M.2 periferii jako jsou NVMe disky a AI akcelerátory k Raspberry Pi 5. Cena je 12 dolarů.
V Praze o víkendu proběhla bastlířská událost roku - výstava Maker Fair v Praze. I strahovští bastlíři nelenili a bastly ostatních prozkoumali. Přijďte si proto i vy na Virtuální Bastlírnu popovídat, co Vás nejvíce zaujalo a jaké projekty jste si přinesli! Samozřejmě, nejen českou bastlířskou scénou je člověk živ - takže co se stalo ve světě a o čem mohou strahováci něco říct? Smutnou zprávou může být to, že provozovatel Sigfoxu jde do
… více »Kam asi vede IllllIllIIl.llIlI.lI? Zkracovač URL llIlI.lI.
Společnost OpenAI představila svůj nejnovější AI model GPT-4o (o jako omni, tj. vše). Nově také "vidí" a "slyší". Videoukázky na 𝕏 nebo YouTube.
Ondřej Filip publikoval reportáž z ceremonie podpisu kořenové zóny DNS. Zhlédnout lze také jeho nedávnou přednášku Jak se podepisuje kořenová zóna Internetu v rámci cyklu Fyzikální čtvrtky FEL ČVUT.
Společnost BenQ uvádí na trh novou řadu monitorů RD určenou pro programátory. První z nich je RD240Q.
Byl aktualizován seznam 500 nejvýkonnějších superpočítačů na světě TOP500. Nejvýkonnějším superpočítačem nadále zůstává Frontier od HPE (Cray) s výkonem 1,206 exaFLOPS. Druhá Aurora má oproti loňsku přibližně dvojnásobný počet jader a dvojnásobný výkon: 1,012 exaFLOPS. Novým počítačem v první desítce je na 6. místě Alps. Novým českým počítačem v TOP500 je na 112. místě C24 ve Škoda Auto v Mladé Boleslavi. Ostravská Karolina, GPU
… více »Před pár týdny jsem narazil na zprávu o novém operačním systému od Microsoft Research jménem Singularity. Mělo to být něco nového, bezpečného, navrženého od nuly, žádné tweaklé Windows ani Unix. Neodolal jsem a vrhl jsem se na studium příslušného reportu. Předpokládám, že ne každý má dost času a chuti číst takové reporty, tak přináším pár postřehů.
Cílem projektu bylo navrhnout operační systém nezatížený jakoukoliv zpětnou kompatibilitou s primárním ohledem na bezpečnost a spolehlivost (tedy ne rychlost) a vytvořit zkušební implementaci. To vše se zapojením moderních vysokoúrovňových jazyků ala C# a jeho nadstaveb.
Celý návrh Singularity stojí na pojmu SIP - software isolated process (dále budu slovo proces používat jako synonymum k SIP). Tak jako v každém jiném operačním systému i v Singularity jsou procesy. Tyto procesy je vhodné od sebe nějak izolovat. Singularity, na rozdíl od všech běžných OS, k tomu nepoužívá hardwarové prostředky, ale softwarové.
Proces je obvykle vymezen svými daty (adresový prostor) a vlákny provádění. K SIP se ale neváže adresový prostor, nýbrž objektový prostor. V Singularity může více procesů sdílet jeden adresový prostor a přesto můžou být na sobě dokonale nezávislé.
Jednotlivé procesy jsou z datového hlediska množiny objektů (jak je známe z Javy a C#) a není dovoleno, aby objekty z různých procesů na sebe měly reference. Jednotlivé procesy spolu samozřejmě můžou komunikovat, ale jenom pomocí přesně a předem definovaných rozhraní, které exportují. Tato rozhraní kromě samotných formátů zpráv (jméno metody a typy parametrů) obsahují i jakýsi protokol (diagram přechodů).
contract C1 { in message Request(int x) requires x>0; out message Reply(int y); out message Error(); state Start: Request? -> (Reply! or Error!) -> Start; }
Zde například proces specifikuje, že přijímá zprávu Request
s parametrem celým kladným číslem. Na tuto zprávu odpoví (viz vyřičník) zprávou Reply
nebo Error
a po odpovědi je znovu schopen přijmout zprávu Request
(stav Start
).
Kromě posílání zpráv si procesy můžou vyměňovat data pomocí tzv. kanálů s využitím tzv. exchange heap.
Na procesy jsou kladeny taky další omezení, proces například nemůže dynamicky nahrát a spustit další kód. Dokonce je zakázána i reflexe (vytváření nového kódu za běhu). Jenže dynamické nahrávání kódu je potřeba, moderní software je jím prolezlý, třeba rozšížení Firefoxu. Vyřešeno je to jednoduše, každé rozšíření musí mít vlastní SIP. Tím je zabráněno tomu, aby nějaké agresivní rozšíření manipulovalo s daty mateřského programu způsobem, který by vedl k jeho pádu.
Skoro každá prkotina má vlastní SIP. Počínaje ovladači a pluginama konče. Díky tomu, že jednotlivé SIP jsou od sebe dokonale odděleny, je možné je po havárii jednoduše odstřelovat, uvolňovat jejich prostředky a taky dělat restarty.
Paměťníci možná vzpomenou na "operační systémy" jako Windows 3.x, kde se do jisté míry spoléhalo na ukázněnost procesů a jako celek to nefungovalo. Jak jsou tedy procesy k ukázněnosti přinuceny v Singularity? Singularity je napsán v Sing#, což je rozšíření Spec#, což je rozšíření C# . A pokud budete psát vlastní program je potřeba ho napsat ve vysokoúrovňovém jazyku překládaném do MSIL. A kód v MSIL umí Singularity ověřit na korektnost. Je to jasné, v Javě taky nemůžete přímo pracovat s pamětí.
Aby nedošlo k dojmu, že všechno musí být v C#. Každý proces může používat rozdílné runtime knihovny, mít jiný algoritmus pro GC. Jen musí dodržovat pravidla systému.
V singularity teoreticky (snad) může běžet i nativní stroják procesoru, ale ten musí být vyprodukován "důvěryhodným" překladačem.
Softwarová izolace má taky ten zajímavý důsledek, že v Singularity na x86 běží všechen software s úrovní oprávnění ring 0. Tato nezávislost na bezpečnostních vlastnostech hardwaru je zároveň příležitost pro vývoj nového hardwaru. Například místo ochrany paměti vytvořit akcelerovaný GC.
Singularity je mikrokernel. Dole je pár řádek v assembleru a céčku a vše ostatní (včetně ovladačů) je v C# a potomcích. Zdá se, že by to mělo být pomalé. Kupodivu není.
Mikrokernel jako například HURD je pomalý zčásti proto, že komponenty běží v oddělených adresových prostorech. Kvůli každé operaci (kopírování dat) se pak musí typicky několikrát přepínant kontext procesu a taky se čeká, než se proces naplánuje.
V Singularity běžící na 64bitové architektuře můžou všechny procesy běžet v jednom adresovém prostoru. Exchange heap pak má mechanismy, jak předat data bez zbytečného kopírování.
Součástí reportu jsou i benchmarky. Singularity vychází ze srovnání s Windows XP, Linuxem a FreeBSD se ctí. Koncepce samotná má z výkonového hlediska IMHO šanci obstát.
Tiskni Sdílej:
Singularity vychází ze srovnání s Windows XP, Linuxem a FreeBSD se ctí.Osobně bych to nazval tragédie, ale to záleží na úhlu pohledu
IMHO anketa nemá zmysel. Ani takáto architektúra nemôže nijak ovlyvniť užívateľovú prácu a jeho pohľad na... jeho tupý pohľad na obrazovku :D. Samozrejme, pokiaľ výrobca nenasadí ďalšoiu marketingovú taktiku (premakanejšiu než pro jeho produkt) a kopletne nezmení UI.
IMHO syngularity je len čiena diera, nič viac. Ten projekt nie je zameraný na stabilitu, ale na nekompatibilitu. O multiplatformových aplikáciách sa tu ani nemôžeme baviť.
Jen bych upozornil na existujici, funkcni, komercni POSIX mikrokernel QNX Neutrino.
a neco z jejich stranek:
The QNX Neutrino microkernel implements the core POSIX features used in embedded realtime systems, along with the fundamental QNX Neutrino message-passing services. The POSIX features that aren't implemented in the microkernel (file and device I/O, for example) are provided by optional processes and shared libraries.
Architecturally, the OS addresses the context-switch performance issue first. In fact, threads and processes provide nearly identical context-switch performance numbers. QNX Neutrino's process-switch times are faster than UNIX thread-switch times. As a result, QNX Neutrino threads don't need to be used to solve the IPC performance problem; instead, they're a tool for achieving greater concurrency within application and server processes.