Vláda USA nařídila společnosti Anthropic pozastavit přístup k modelům Fable 5 a Mythos 5 pro všechny cizince, včetně zaměstnanců Anthropicu.
Společnost Murena představila (YouTube) novou verzi 4.0 mobilního operačního systému /e/OS (Wikipedie) založeného na Androidu a LineageOS bez aplikací a služeb od Googlu.
V Arch User Repository (AUR) bylo kompromitováno přes 400 opomíjených balíčků (jejich seznam). Útočník do nich začlenil škodlivý npm balíček atomic-lockfile, který krade citlivá data uživatelů. Publikována byla předběžná analýza spouštěného malwaru deps.
Homebrew, správce balíčků nejen pro macOS, byl vydán ve verzi 6.0.0 (seznam změn). Hlavními novinkami jsou bezpečnostní mechanismus tap trust kvůli důvěryhodnosti závislostí, vylepšení sandboxingu na Linuxu, interní JSON API nebo zlepšení výkonu.
Byla nalezena a 9. června opravena kritická zranitelnost ve FreeBSD v Kernel TLS (KTLS). Pojmenována byla Bumsrakete (FreeBSD-SA-26:26.ktls, CVE-2026-45257). Lokální neprivilegovaný uživatel může přepisovat soubory, ke kterým má právo pouze pro čtení. Přepsáním setuid binárky a jejím spuštěním může získat roota. Na všech verzích od verze 13.0 vydané v dubnu 2021.
Vývojáři open source operačního systému ReactOS (Wikipedie), jehož cílem je kompletní binární kompatibilita s aplikacemi a ovladači pro Windows, se na síti 𝕏 pochlubili, že ReactOS zvládne počítačovou hru Half-Life.
Byla vydána nová verze 4.8 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.
Apple container dospěl do verze 1.0.0. Jedná se o open source nástroj pro spouštění linuxových kontejnerů na macOS postavený nad containerization. Napsaný je v programovacím jazyce Swift a optimalizovaný pro Apple silicon.
Bylo vydáno Eclipse IDE 2026-06 aneb Eclipse 4.40. Představení novinek tohoto integrovaného vývojového prostředí také na YouTube.
Asterinas (GitHub) je v Rustu napsané jádro operačního systému poskytující s jádrem Linux kompatibilní ABI. Vydána byla verze 0.18.0. První distribucí postavenou nad jádrem Asterinas je Asterinas NixOS. Nejedná se o oficiální projekt NixOS a nemá nic společného s NixOS Foundation.
mkisofs. Je možné použít také síť, tj. připojit ze z emulovaného počítače na ten skutečný a využít třeba Sambu nebo FTP. Samozřejmě lze zapisovat také přímo z přízakového řádku do virtuálního disku uloženého v souboru. Pokud je v něm pouze jeden oddíl, lze to provést takto (jako root):
mount -o loop,offset=32256 soubor_s_diskem /tmp/nějaký_adresářP.S.: Zrychluje vám kqemu emulaci?
Zkousel jste nekdo qemu 0.8.0, pripadne spis CVS? Nefunguje mi v nem TUN rozhranni pro virtualni sit. Klasicka hlaska:
warning: could not open /dev/net/tun: no virtual network emulationbo neco na ten zpusob, mozna jeste se SIOCSIFADDR: No such device
Po navratu ke starsi verzi v pohode. Zkousel jsem reportovat bug, ale jediny, co se mi vratilo, bylo zvyseny mnozstvi spamu a v CVS na dany tema taky zadny zmeny... :-/
Tohle jsem si navic jeste trochu upravil, aby to nebylo optimalizovany pro 386ku ale i586. Vys to bohuzel zatim nejde, neprojde to kompilaci... :-/
Pokud se to nezkompiluje rucne pro dany jadro v podadresari prislusnyho qemu, tak to podle me snad ani nemuze fungovat. Proste rozbalit qemu, do nej rozbalit kqemu, v qemu napsat:
./configure --prefix=... --target-list=...A pak to zmaknout... A razem to bootuje o vic nez pul minuty rychleji. Stary verze se musej´ kompilovat tahle zcela zcela zavisle a nova verze, co nemusi, je jeste v CVS.
Nevim, jak jsou na tom balicky v jinych distribucich, ale kdyz pouziju emerge pomoci ebuildu, tak se to taky snazi kompilovat kazdy zvlast a vysledek je nefunkcni.
CFLAGS="-O3 -fomit-frame-pointer -march=pentium2" ./configure --prefix=/opt/qemu-0.8.0 --target-list=i386-softmmu --enable-kqemu && make && make installFunguje to, ale jede to pomalu s modulem i bez něj.
FATAL: Error inserting kqemu (/lib/modules/2.6.11-6mdk/misc/kqemu.ko): Invalid module format
preventivně jsem udělal
depmod -a
a vyhledal
crw-rw-rw- 1 root root 250, 0 bře 7 11:01 /dev/kqemu
a teď nevím co dál. Má někdo nápad nebo radu? Používám Mdk2005le.
/dev/kqemu jsou v pořádku, čtení i zápis všem je pohodlná cesta nejmenšího odporu.
qemu-0.8.0 a kqemu-0.7.2. Spouštěl jsem to bez instalovaného kqemu.ko modulu a pak s instalovaným (kontroloval jsem zda je aktivní v monitoru pomocí info kqemu).
Nevíte někdo proč kqemu neurychluje?
mkisofs -o /někde/nějaké.iso -r -J .Parametry
-r -J zajistí správné názvy souborů a další věci dobré pro Unix (-r) i Windows (-J), více je v manuálové stránce.
Při spuštění Qemu je dobré přidat parametr -cdrom /někde/nějaké.iso, systém pak bude pracovat s CD obrazem jako nějakou CD mechanikou. Mechaniky je možné měnit i za chodu, stiskem Control+Alt+2 se zobrazí příkazový řádek Qemu, kde lze příkazem change cdrom /někde/jiné.iso změnit obraz CD. Je možné zadat i přímo zařízení CD-ROM mechaniky, třeba /dev/cdrom, pak bude možné použít skutečné CD. (Je však třeba dát uživateli přístupová práva pro čtení k souboru v /dev.) Pod Windows to je také, jen se místo /dev/cdrom napíše něco jako D:\, ale nevím to jistě, nikdy jsem to nědělal.
Systém spuštěný v Qemu si s falešnou CD mechanikou poradí naprosto bez problémů, z jeho pohledu jde o skutečné CD.
Tiskni
Sdílej: