V dokumentově orientované databázi MongoDB byla nalezena a v upstreamu již opravena kritická bezpečností chyba CVE-2025-14847 aneb MongoBleed.
Při úklidu na Utažské univerzitě se ve skladovacích prostorách náhodou podařilo nalézt magnetickou pásku s kopií Unixu V4. Páska byla zaslána do počítačového muzea, kde se z pásky úspěšně podařilo extrahovat data a Unix spustit. Je to patrně jediný známý dochovaný exemplář tohoto 52 let starého Unixu, prvního vůbec programovaného v jazyce C.
FFmpeg nechal kvůli porušení autorských práv odstranit z GitHubu jeden z repozitářů patřících čínské technologické firmě Rockchip. Důvodem bylo porušení LGPL ze strany Rockchipu. Rockchip byl FFmpegem na porušování LGPL upozorněn již téměř před dvěma roky.
K dispozici je nový CLI nástroj witr sloužící k analýze běžících procesů. Název je zkratkou slov why-is-this-running, 'proč tohle běží'. Klade si za cíl v 'jediném, lidsky čitelném, výstupu vysvětlit odkud daný spuštěný proces pochází, jak byl spuštěn a jaký řetězec systémů je zodpovědný za to, že tento proces právě teď běží'. Witr je napsán v jazyce Go.
Yazi je správce souborů běžící v terminálu. Napsán je v programovacím jazyce Rust. Podporuje asynchronní I/O operace. Vydán byl v nové verzi 25.12.29. Instalovat jej lze také ze Snapcraftu.
Od soboty do úterý probíhá v Hamburku konference 39C3 (Chaos Communication Congress) věnovaná také počítačové bezpečnosti nebo hardwaru. Program (jiná verze) slibuje řadu zajímavých přednášek. Streamy a záznamy budou k dispozici na media.ccc.de.
Byl představen nový Xserver Phoenix, kompletně od nuly vyvíjený v programovacím jazyce Zig. Projekt Phoenix si klade za cíl být moderní alternativou k X.Org serveru.
XLibre Xserver byl 21. prosince vydán ve verzi 25.1.0, 'winter solstice release'. Od založení tohoto forku X.Org serveru se jedná o vůbec první novou minor verzi (inkrementovalo se to druhé číslo v číselném kódu verze).
Wayback byl vydán ve verzi 0.3. Wayback je "tak akorát Waylandu, aby fungoval Xwayland". Jedná se o kompatibilní vrstvu umožňující běh plnohodnotných X11 desktopových prostředí s využitím komponent z Waylandu. Cílem je nakonec nahradit klasický server X.Org, a tím snížit zátěž údržby aplikací X11.
Byla vydána verze 4.0.0 programovacího jazyka Ruby (Wikipedie). S Ruby Box a ZJIT. Ruby lze vyzkoušet na webové stránce TryRuby. U příležitosti 30. narozenin, první veřejná verze Ruby 0.95 byla oznámena 21. prosince 1995, proběhl redesign webových stránek.
checkrestart?
checkrestart nikdy neslyšel, takže děkuji. Určitě se na něj podívám, zkusím prozkoumat, jak to řeší oni.
Potom, BP pochází z RedHatu a jejich požadavkem bylo, aby ten nástroj byl funkční i na Fedoře. Což checkrestart nejspíš nesplňuje.
PS: Zrovna jsem to nainstaloval, vyzkoušel a subjektivně si myslím, že nemají příliš user-friendly výstup.
...v kvetnu jsem v nem opravovalo...Melo to byt "v kvetu se v nem opravovalo...", ja sam je neopravoval, jen jsem na jednu z nich narazil.
needs-restarting vím. Jako problém vidím to, že není user-friendly (stejně tak jako checkrestart pro debian, zmíněný výše. Už jen první pohled
[frostyx@localhost ~]$ sudo needs-restarting 1385 : gvim -f 961 : xfce4-terminal --geometry=80x24 --display :0.0 --role=xfce4-terminal-1404752667-2093205702 --show-menubar --show-borders --hide-toolbar --working-directory /home/frostyx --window --geometry=135x32 --display :0.0 --role=xfce4-terminal-1404680775--1537418211 --show-menubar --show-borders --hide-toolbar --working-directory /home/frostyx/dotfiles --tab --working-directory /home/frostyx/dotfiles/.vim/bundle/YouCompleteMe --sm-client-id 2163acf15-c689-4f32-b713-6d1b1c824234Oproti
[frostyx@localhost ~]$ sudo tracer gvim xfce4-terminalNavíc tracer umožňuje definovat pravidla pro konkrétní procesy. Takže mu můžu říci, že mě s nějakými polkit, udisks a gvfs procesy nemá otravovat, protože je stejně nemůžu restartovat. To je samozřejmě řízeno daty, takže v současné době existuje systémový soubor, který bude brzy obohacen o uživatelsky definovaný soubor někde v /etc případně /home. Taky si hlídám to, že nějaký proces spustil jiný a měl by být restartován za pomocí toho nadřazeného. Například jsem aktualizoval flash player, tak nechci aby se vypsal flash player, protože je ve skutečnosti potřeba restartovat chromium, aby se změna projevila.
Na openSUSE je 'zypper ps', který vypíše seznam programů a knihoven, jež se dotkl upgrade/dist-upgrade a je dobré je restartovat.
nebo zkus vymyslet nějakou zkratku (ideálně rekurzivní jako GNU nebo Wine), která bude relativně jedinečná.Manjaro (Archlinux), tak nemůžu ozkoušet, ale co pro tento proces:
/usr/bin/python2 /usr/share/system-config-printer/applet.py
upozorní mě to při povýšení system-config-printer, že mám restartovat system-config-printer-applet?
Jinak zajímavý počin
Pokud je některá z knihoven, nebo samotná aplikace po dobu jejího běhu aktualizována...
Eeeee?
Když spustíme aplikaci, do paměti se načtou knihovny a soubory potřebné k jejímu běhu. Pokud je některá z knihoven, nebo samotná aplikace po dobu jejího běhu aktualizována, ...Po dobu běhu té aplikace ... nevím, mě to zní normálně. Je to špatně?
Pokud jsou soubory některé z knihoven nebo samotné aplikace po dobu jejího běhu aktualizovány, ...Jde o to, že ty staré soubory mohou stále být na disku dokud jsou otevřené (platí automaticky pro binárku i knihovny běžícího procesu), protože soubor je smazaný až tehdy, když počet referencí na něj klesne na nulu. Běžící proces může s takovým souborem víceméně normálně pracovat, ale pro ostatní procesy je normálnímy prostředky nedostupný. PS: Je možné udělat takovýto program i bez podpory balíčkovacího systému, pokud by prolezl všechny procesy v
/proc a kouknul se, jesli některý nemá smazanou binárku nebo knihovnu (skrz soubor exe a maps), případně jestli nedrží otevřené soubory, které jsou smazané (symlinky v adresáři fd). Jen je třeba dát pozor na vlákna jádra, protože ty žádnou binárku nemají, ale není problém je poznat, protože nemají nic namapovaného a nemají nastavené prostředí. Jediná nevýhoda by byla, že by vypsal jen procesy, ale ne aplikace/služby. nicméně pokročilému uživateli by to nejspíš nevadilo ...
Jde o to, že ty staré soubory mohou stále být na disku dokud jsou otevřené (platí automaticky pro binárku i knihovny běžícího procesu), protože soubor je smazaný až tehdy, když počet referencí na něj klesne na nulu. Běžící proces může s takovým souborem víceméně normálně pracovat, ale pro ostatní procesy je normálnímy prostředky nedostupný.Já myslel, že ten proces má všechny soubory potřebné k běhu načtené v paměti a přistupuje k nim do paměti, ne na disk. Z hlediska implementace na tom stejně nezáleží, ale až budu psát dokumentaci k BP, tak si k tomu rozhodně něco přečtu, ať tam nenapíšu hlouposti. Díky.
Je možné udělat takovýto program i bez podpory balíčkovacího systému, pokud by prolezl všechny procesy v /proc a kouknul se, jesli některý nemá smazanou binárku nebo knihovnuTakže vlastně
lsof |grep deleted, najít cesty do souborového systému a ty procesy vypsat? To zní až moc jednoduše
. Zkusím to.
IMHO bude potřeba zkombinovat oba přístupy – předmětem aktualizace můžou být i datové soubory nebo třeba skript, který se jednou načte a pak už se jako otevřený soubor nedrží.
alias vyhnite='lsof | grep '\''DEL.*lib'\'' | cut -f 1 -d '\'' '\'' | sort -u'
Tiskni
Sdílej: