sudo-rs, tj. sudo a su přepsané do programovacího jazyka Rust, již obsaženo v Ubuntu 25.10, bylo vydáno ve verzi 0.2.10. Opraveny jsou 2 bezpečnostní chyby.
Kaspersky pro Linux je nově k dispozici také pro domácí uživatele.
Společnost Avalonia UI oznámila, že pracuje na .NET MAUI pro Linux a webový prohlížeč. Vyzkoušet lze demo v prohlížeči. Když bude backend stabilní, bude vydán jako open source pod licencí MIT.
Byl vydán Mozilla Firefox 145.0. Přehled novinek v poznámkách k vydání a poznámkách k vydání pro vývojáře. Ukončena byla podpora 32bitového Firefoxu pro Linux. Přidána byla podpora Matrosky. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 145 bude brzy k dispozici také na Flathubu a Snapcraftu.
Lidé.cz (Wikipedie) jsou zpět jako sociální síť s "ambicí stát se místem pro kultivované debaty a bezpečným online prostředím".
Byla vydána nová verze 4.4 multiplatformního integrovaného vývojového prostředí (IDE) pro rychlý vývoj aplikaci (RAD) ve Free Pascalu Lazarus (Wikipedie). Využíván je Free Pascal Compiler (FPC) 3.2.2.
ASUS má v nabídce komplexní řešení pro vývoj a nasazení AI: kompaktní stolní AI superpočítač ASUS Ascent GX10 poháněný superčipem NVIDIA GB10 Grace Blackwell a platformou NVIDIA DGX Spark. S operačním systémem NVIDIA DGX založeném na Ubuntu.
Desktopové prostredie Trinity Desktop vyšlo vo verzii R14.1.5. Je tu opravená chyba v tqt komponente spôsobujúca 100% vyťaženie cpu, dlaždice pre viac monitorov a nemenej dôležité su dizajnové zmeny v podobe ikon, pozadí atď. Pridaná bola podpora distribúcií Debian Trixie, Ubuntu Questing, RHEL 10 a OpenSUSE Leap 16.
Grafická aplikace Easy Effects (Flathub), původně PulseEffects, umožňující snadno povolovat a zakazovat různé audio efekty v aplikacích používajících multimediální server PipeWire, byla vydána ve verzi 8.0.0. Místo GTK 4 je nově postavená nad Qt, QML a Kirigami.
Na YouTube lze zhlédnout Godot Engine – 2025 Showreel s ukázkami toho nejlepšího letos vytvořeného v multiplatformním open source herním enginu Godot.
Prozatím lze všechny příkazy, které jsme si ukazovali, zařadit mezi tzv. souběžné příkazy - všechny se provádí najednou bez ohledu na pořadí. V obvodové realizaci to ukazuje na paralelní obvody. Pomocí procesu můžeme použít příkazy sekvenční, kde naopak pořadí příkazů hraje důležitou roli. Proces sám o sobě je jeden souběžný příkaz.
Sekvenční zpracování příkazů v procesu se řídí následujícími pravidly:
Proces můžeme také chápat jako myšlenkovou přípravu na vytvoření
signálů. Nejlepší bude ukázat si činnost procesu na příkladu.
Předpokládejme dvě různé architektury k entitě example_1
(deklaraci entity neuvádím), která má pouze jeden výstupní signál
O:
ARCHITECTURE arch_1 OF example_1 IS BEGIN O <= '1'; O <= '0'; END arch_1;
ARCHITECTURE arch_2 OF example_1 IS
BEGIN
p_1: process
begin
O <= '1';
O <= '0';
end process;
END arch_2;
V prvním případě se snažíme do výstupního signálu O
napojit současně dvě hodnoty - log. '1' a log. '0'. To by mohlo mít v
reálném obvodu katastrofální následky. Pokud například uvažujeme logiku,
kde log. '1' znamená připojení na +5V a log. '0' připojení na zem,
zapisujeme tímto kódem zkrat. Ve druhém případě se ale příkazy
zpracovávají sekvenčně. Druhý přiřazovací příkaz "přebije" první a na
výstupu O bude '0';
V procesu není možné použít souběžný příkaz when, místo
něj můžeme aplikovat sekvenční příkaz if. Uvažujme příklad
z minulého
dílu, kde jsme vytvořili multiplexor pomocí příkazu
O <= I1 when A = '0' else I2
V procesu by vypadal zápis tohoto multiplexoru následovně:
p_1: process (I1, I2, A)
begin
if A = '0' then
O <= I1;
else
O <= I2;
end if;
end process;

Zaměřme se nyní více na syntaxi procesu. Před klíčovým slovem
process je návěští, v našem případě p_1. To je
důležité pro případnou identifikaci procesu v průběhu simulace nebo
syntézy. Za klíčovým slovem process je tzv. sensitivity
list. V něm říkáme simulátoru, kdy má proces spustit a obnovit hodnoty
výstupních signálů. Tento výpočet provede simulátor právě při změně
libovolného signálu obsaženého v sensitivity listu. V praxi to znamená, že
do sensitivity listu je třeba zapsat všechny signály, které do procesu
vstupují. V našem případě jsou to signály I1, I2
a A.
Vezměme nyní následující proces:
p_1: process (I1, I2, A)
begin
O <= I2;
if A = '0' then
O <= I1;
end if;
end process;
Tento zápis je zcela identický s předchozím procesem. Nejdříve do
výstupního signálu O přiřazujeme signál I2, ale
v případě, že je hodnota signálu A '0', dostane se ke slovu
přiřazovací příkaz O <= I1. Výsledek je tedy
opět stejný multiplexor.
Nyní uděláme malou odbočku k tomu, jakým způsobem psát design. Budeme
hovořit o synchronním designu, tzn. v obvodu se vyskytuje jediný hodinový
signál clk. Dnešním standardem je jasně rozdělit design na
registry (paměťové prvky, realizovatelné např. klopným obvodem D) a
kombinační logiku (prvky AND, OR, NOT...) bez cyklů. Registry jsou všechny
taktovány na stejnou (např. náběžnou) hranu clk. V okamžiku
této náběžné hrany se přepíše signál ze vstupu registru na výstup.
Následuje cesta signálu přes kombinační logiku, než dorazí na vstup
dalšího registru. Jakmile všechny signály projdou přes logiku a ustálí se,
může přijít další náběžná hrana hodin a celý proces se opakuje.

Z toho vyplývá i maximální frekvence hodin. Jejich perioda musí být minimálně taková, aby se signál ustálil i na nejdelší cestě v celém obvodu. Pokud tedy taktujeme např. procesor na 1600 MHz, znamená to, že nejdelší cestou (mezi dvěma registry spojenými pouze logikou) v jeho designu projde signál za méně než 0,625 nanosekundy.
Podívejme se nyní na následující proces:
p_1: process (I1, I2, A)
begin
if A = '0' then
O <= I1;
end if;
end process;
Pokud má signál A hodnotu '0', bude na výstupu
I1. Co ale když bude A '1'? To potom znamená
zachovat na výstupu aktuální hodnotu. A zde se dostáváme k jádru problému.
K zachování hodnoty potřebujeme paměťový prvek. V tomto konkrétním případě
bude tvořen zpětnou vazbou, např. takto:

A právě tato zpětná vazba (latch) není přípustná. Proč je vlastně zpětná vazba v logice problém? Např. může zmást syntezátor při počítání délky cesty v obvodu. Obvod potom může fungovat, ale také nemusí (což většinou nastane v nejméně vhodnou dobu).
Jaký z toho plyne závěr? V příkazu if (pokud proces
netvoří registr, ukážeme si příště) je třeba vždy pokrýt všechny stavy
vstupních signálů pro výstupní signály. Jinými slovy, každý výstupní
signál musí mít jasně definovanou hodnotu pouze v závislosti na vstupních
signálech. Podobný problém může nastat i u souběžného signálu
when - tam je také vhodné vždy uvádět klauzuli
else.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej: