Po 9 týdnech vývoje od vydání Linuxu 7.0 oznámil Linus Torvalds vydání Linuxu 7.1. Přehled novinek a vylepšení na LWN.net: první a druhá polovina začleňovacího okna a časem také na Linux Kernel Newbies.
Cheat Engine (Wikipedie) je s verzí 7.7 k dispozici už také pro Linux. Jedná se o proprietární skener/debugger paměti používaný především k cheatování v počítačových hrách.
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.
Ohledně té pomalosti. V jednom obchodě jsem držel v jedné ruce Ifon a druhé G1 (mají stejný procesor, nějaký ARM). G1 měl svižnějží odezvu Gui a aplikace se rychleji spouštěly. A podle ohlasů na netu okolo povyku s BFS schedulerem existují pro nějaký Android Cyano ROM s BFS, se kterým prý dostanete pocit výměny hardware za mnohem výkonnější .
Velice mě zklamalo to, že jsem večer odložil telefon nabitý na 60 % a ráno byl vypnutý kvůli prázdné baterii – nedovedu si vysvětlit, co se tam dělo, že to dokázalo tolik spotřebovat.WiFi. S vypnutým WiFi jsem telefon lehce používal tři dny (nějaké přečtení e-mailů, instalace dvou třech aplikací, trochu je vyzkoušet, žádné telefonáty, žádné přehrávání hudby) – a z plně nabité baterky jsem se dostal zhruba na 50 %. Druhý den jsem dopoledne zapnul WiFi, za pár hodin po zjištění, jak žere baterku, jsem ho zase vypnul, a večer už jsem se dostal k varování 15 % nabité baterky (a oranžový symbol baterky), pak červený symbol baterky a nakonec jen blikání oranžové ledky a telefon nešel „probudit“ (ale byl pořád zapnutý, po zapojení do nabíječky jej šlo okamžitě odemknout a normálně s ním pracovat). Za dvě hodiny nabíjení byla baterka opět plná.
To také není nejšikovnější řešení. To dělají i Windows Mobile. Pokud něco stahuje při "vypnutém" mobilu, jsou dvě možnosti - WiFi se zapne (a bude žrát vesele dál), nebo to bude stahovat přes mobilní síť (což zase nepotěší lidi s placením za přenesená data). Obě řešení mají své pro a proti a osobně se mi řešení u Hera líbí víc než zmíněné vypínání WiFi. Nechat mobil přes noc na kabelu není problém a aspoň během noci může udělat všechny synchronizační a stahovací záležitosti tak, aby s tím nevyčerpával baterii přes den.
Paměti RAM má Hero více než mnohý starý desktop – 512 MB
na ofic stranke pisu ze pamet RAM je 288 MB a pamet ROM ma 512 MB
Jsou někde na webu nějaké pěkné testy výkonu JRE pro G1? Napsal jsem pro Android šachový program (http://honzovysachy.sourceforge.net/) a výkon na telefonu mě dost nepříjemně překvapil. I když mi bylo jasné, že to bude o dost pomalejší, než když pustím stejný javovský kód na normálním JRE na svém notebooku. (Ne v androidím emulátoru, tam je to taky pomalé, ale jako normální javovskou PC aplikaci s AWT místo androidího GUI.) Rozdíl je ještě větší, než jsem čekal. Nejde mi o rychlost např. práce se soubory, alokací, GUI a podobně, spíš o rychlost kódu algoritu tj. aritmeticko-logické operace, přístup do pole, volání metod atd. Kolikrát by tohle mělo být pomalejší než na normálním dnešním PC?
No já vím, ale ono je to na té G1 asi 80 pomalejší. Místo tří miliónů pozic mi to vyhodnotí jen necelých čtyřicet tisíc. To jsem přece jenom nečekal. Až se naučím volat a překládat na Androidu nativní kód v C, tak schválně vyzkouším, jaký poměr bude tady. Jestli je to zpomalení oproti PC spíš špatným JRE a nebo procesorem.
Tiskni
Sdílej: