V aktuálním příspěvku na blogu počítačové hry Factorio (Wikipedie) se vývojář s přezývkou raiguard rozepsal o podpoře Linuxu. Rozebírá problémy a výzvy jako přechod linuxových distribucí z X11 na Wayland, dekorace oken na straně klienta a GNOME, změna velikosti okna ve správci oken Sway, …
Rakudo (Wikipedie), tj. překladač programovacího jazyka Raku (Wikipedie), byl vydán ve verzi #171 (2024.04). Programovací jazyk Raku byl dříve znám pod názvem Perl 6.
Společnost Epic Games vydala verzi 5.4 svého proprietárního multiplatformního herního enginu Unreal Engine (Wikipedie). Podrobný přehled novinek v poznámkách k vydání.
Byl vydán Nextcloud Hub 8. Představení novinek tohoto open source cloudového řešení také na YouTube. Vypíchnout lze Nextcloud AI Assistant 2.0.
Vyšlo Pharo 12.0, programovací jazyk a vývojové prostředí s řadou pokročilých vlastností. Krom tradiční nadílky oprav přináší nový systém správy ladících bodů, nový způsob definice tříd, prostor pro objekty, které nemusí procházet GC a mnoho dalšího.
Microsoft zveřejnil na GitHubu zdrojové kódy MS-DOSu 4.0 pod licencí MIT. Ve stejném repozitáři se nacházejí i před lety zveřejněné zdrojové k kódy MS-DOSu 1.25 a 2.0.
Canonical vydal (email, blog, YouTube) Ubuntu 24.04 LTS Noble Numbat. Přehled novinek v poznámkách k vydání a také příspěvcích na blogu: novinky v desktopu a novinky v bezpečnosti. Vydány byly také oficiální deriváty Edubuntu, Kubuntu, Lubuntu, Ubuntu Budgie, Ubuntu Cinnamon, Ubuntu Kylin, Ubuntu MATE, Ubuntu Studio, Ubuntu Unity a Xubuntu. Jedná se o 10. LTS verzi.
Na YouTube je k dispozici videozáznam z včerejšího Czech Open Source Policy Forum 2024.
Fossil (Wikipedie) byl vydán ve verzi 2.24. Jedná se o distribuovaný systém správy verzí propojený se správou chyb, wiki stránek a blogů s integrovaným webovým rozhraním. Vše běží z jednoho jediného spustitelného souboru a uloženo je v SQLite databázi.
Byla vydána nová stabilní verze 6.7 webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 124. Přehled novinek i s náhledy v příspěvku na blogu. Vypíchnout lze Spořič paměti (Memory Saver) automaticky hibernující karty, které nebyly nějakou dobu používány nebo vylepšené Odběry (Feed Reader).
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.