O víkendu probíhá konference OpenAlt 2025 (Stream). Na programu je spousta zajímavých přednášek. Pokud jste v Brně, stavte se. Vstup zdarma.
Josef Průša představil novou velkoformátovou uzavřenou CoreXY 3D tiskárnu Prusa CORE One L a nový open source standard chytrých cívek OpenPrintTag i s novou přepracovanou špulkou.
Na GOG.com běží Autumn Sale. Při té příležitosti je zdarma hororová počítačová hra STASIS (ProtonDB: Platinum).
Ubuntu 25.10 má nově balíčky sestavené také pro úroveň mikroarchitektury x86-64-v3 (amd64v3).
Byla vydána verze 1.91.0 programovacího jazyka Rust (Wikipedie). Podrobnosti v poznámkách k vydání. Vyzkoušet Rust lze například na stránce Rust by Example.
Ministerstvo průmyslu a obchodu vyhlásilo druhou veřejnou soutěž v programu TWIST, který podporuje výzkum, vývoj a využití umělé inteligence v podnikání. Firmy mohou získat až 30 milionů korun na jeden projekt zaměřený na nové produkty či inovaci podnikových procesů. Návrhy projektů lze podávat od 31. října do 17. prosince 2025. Celková alokace výzvy činí 800 milionů korun.
Google v srpnu oznámil, že na „certifikovaných“ zařízeních s Androidem omezí instalaci aplikací (včetně „sideloadingu“) tak, že bude vyžadovat, aby aplikace byly podepsány centrálně registrovanými vývojáři s ověřenou identitou. Iniciativa Keep Android Open se to snaží zvrátit. Podepsat lze otevřený dopis adresovaný Googlu nebo petici na Change.org.
Byla vydána nová verze 18 integrovaného vývojového prostředí (IDE) Qt Creator. S podporou Development Containers. Podrobný přehled novinek v changelogu.
Cursor (Wikipedie) od společnosti Anysphere byl vydán ve verzi 2.0. Jedná se o multiplatformní proprietární editor kódů s podporou AI (vibe coding).
Google Chrome 142 byl prohlášen za stabilní. Nejnovější stabilní verze 142.0.7444.59 přináší řadu novinek z hlediska uživatelů i vývojářů. Podrobný přehled v poznámkách k vydání. Opraveno bylo 20 bezpečnostních chyb. Za nejvážnější z nich bylo vyplaceno 50 000 dolarů. Vylepšeny byly také nástroje pro vývojáře.
Chtěl jsem přenosný Linux. Volba padla na 32bitový (tedy zkompilovaný pro i686) Arch Linux a jako médium externí USB pevný disk Adata. Na notebooku HP ProBook 4530s jsem měl 64bitový Arch Linux a byl jsem velmi nespokojený s jeho výkonem (systém se dost hřál a hlavně webové prohlížeče (dokonce i Chromium) chodily hrozně pomalu, čekal jsem třeba i 5 sekund na reakci). Tak jsem na něm vyzkoušel ze zvědavosti ten externí i686 Arch. Byl jsem mile překvapen -- chodí to mnohem svižněji (rychleji) a taky se to míň hřeje! A tak jsem překopíroval ten 32bitový Arch na interní disk v notebooku a jsem s výkonem spokojený.
Přitom mi ale na stolním PC (4jádrový AMD Athlon, 4 GB paměti) chodí 64bitový Arch Linux celkem svižně. Tak nevím, kde je zakopaný pes, co se týká toho notebooku. Ten notebook má procesor Intel Core i3 (Sandy Bridge) a k tomu 4 GB paměti. Jo a z výpisu příkazu free jsem vyčetl, že ten 64bitový Arch na notebooku používal mnohem méně RAMky (pro cachování) než ten 32bitový Arch.
Tiskni
Sdílej:
To vím taky. Ale co? Špatně se to hledá.
Ale jinak máš pravdu.
Paměť. Mám teď v notebooku 4G (protože s 8 mi padá a potřebuju ho vyzkoušet s originální pamětí) a je to utrpení. Zrovna Chromium je schopný sežrat úplně neuveřitelný množství paměti.
free -h:
total used free shared buffers cached
Mem: 2,7G 2,1G 587M 0B 39M 1,7G
-/+ buffers/cache: 312M 2,4G
Swap: 6,0G 0B 6,0G
Mám puštěný Chromium (v něm otevřené dva taby), pekwm (resp. Xorg), pár terminálů..
Dost divný je, že ukazuje "total" jenom 2,7G, i když mám v notebooku 4G!?
Dost divný je, že ukazuje "total" jenom 2,7G, i když mám v notebooku 4G!?Pokud je to 32bitový systém, tak to má vcelku logiku. Standardní dělení adresního prostoru je 1 GB pro jádro a 3 GB pro procesy (přičemž každý proces má virtuální adresní prostor také 3 GB). Předpokládám, že program
free část paměti vyhrazenou pro jádro ignoruje. Ale to je jen můj odhad, 32bitový systém jsem snad na 4 GB paměti nikdy nezkoušel. Pak je tam ještě rozpor 2,7 vs. 3,0, který může být způsobený využitím části paměti pro grafickou kartu.
[ 0.000000] 1880MB HIGHMEM available. [ 0.000000] 887MB LOWMEM available.
Tak jsem prolezl BIOS setup a nic o přidělování RAMky grafické kartě tam není a možnost paměť zakázat taky ne. Ale nemůže na to mít vliv, že mám jednu grafiku přímo v procesoru Intel Core i3 (Sandy Brigde) a potom ještě ATI/AMD Radeon?
Vyzkouším ještě zakázat "přepínání" grafik (tedy té v proceru a dedikovanou ATI). Ale kolik si ta grafika v procesoru ukousne, to nastavit nelze.
To deleni se tyka jednotlivych procesu.To dělení se týká celého prostoru. Virtuální prostor 4 GB se rozdělí na 1 GB pro jádro a 3 GB pro procesy. Každý proces má virtuálně k dispozici ty 3 GB, z fyzické paměti mohou procesy v součtu využívat i podstatně více (pokud sdílejí stejné stránky). Tohle je default, ale lze to při kompilaci jádra změnit. Týká se to samozřejmě jen 32bitového systému, u 64bitového to není potřeba.
Pamet mu nejspis sezral BIOS. 1GB RAM fuc je treba u Intel desek bezne.Zajímavé. K čemu jiném by to BIOS žral, než k přidělení grafické kartě? To by mě fakt zajímalo...
At se podiva do dmesg na HIGHMEM available a LOWMEM available.Spíš do /proc/meminfo, kde je stav paměti docela přehledně zobrazen (a důležité jsou položky LowTotal a HighTotal). Jinak by bylo dobré říct, co ty jednotlivé zóny paměti znamenají. U 4 GB je adresní prostor standardně rozdělen tak, že dolní 3 GB jsou pro procesy (virtuální adresace) a horní 1 GB pro jádro. Z něj je přímo namapováno 896 MB (dolní paměť složená ze zón DMA a NORMAL) a pak je tam oblast 128 MB používaná pro mapování z horní paměti (HIGHMEM). Horní paměť je ta část fyzické paměti, která se neadresuje přímo, nýbrž jen právě přes toto namapování, které je vždy jen dočasné. Při kompilaci jádra jde to dělení zrušit, pak se adresuje přímo, ale jen do 1 GB (i když zase bez rezervování toho mapovacího prostoru, který by byl jinak využitelný jen přes mapování, čili se ušetří něco málo režie). Jde tedy ve stručnosti o to, kolik paměti je k dispozici v součtu a o kolik se to liší od instalované paměti. Pokud tam ta paměť bude chybět, pak ji jádro vůbec nevidí.
beta:~ # dmidecode
..
BIOS Information
Vendor: Intel Corporation
Version: SE7221BK1E.86B.P.08.00.0034.063020060918
..
Memory Array Mapped Address
Starting Address: 0x00000000000
Ending Address: 0x000CFFFFFFF
Range Size: 3328 MB
..
Memory Device
Array Handle: 0x0023
Error Information Handle: Not Provided
Total Width: 72 bits
Data Width: 64 bits
Size: 2048 MB
Form Factor: DIMM
Set: 2
Locator: DIMM_1A
..
Memory Device
Array Handle: 0x0023
Error Information Handle: Not Provided
Total Width: 72 bits
Data Width: 64 bits
Size: 2048 MB
Form Factor: DIMM
Set: 1
Locator: DIMM_1B
..
Tech stovek je tak sedm a se starsim BIOSem bylo devet.
To jsem nepochopil. 
Díky. No jo, 64 bit vyhrál. Asi to bude nějakou aktualizací jádra či jiného softwaru, protože v minulosti (víc než 1 rok) to chodilo krásně i s 64bitovým Arch Linuxem.
Je v AUR. Zrovna ho kompiluju. Díky.
V Arch Linuxu (zatím) není v oficiálním jádře pro i686 PAE povoleno.
Tak jedu na jádře s PAE (3.10.5-1-pae):
[ 0.000000] 4476MB HIGHMEM available. [ 0.000000] 891MB LOWMEM available.
+1
Vzpomínám jak jsem před lety na AMD Athlon 3000+ (s754) přešel z 32-bit Ubuntu na 64-bit verzi. Boot za poloviční dobu, rychlejší reakce na všechno,...a od té doby jedu na 64-bitu všude, kde to jde 
Mám opačnou zkušenost -- tedy, co se týká notebooku (viz výše).
Bude to rok co ho nepoužívám a nemám si na co stěžovat, můj život je zase o něco klidnější a exotičtější. Jen videa na Youtube musím spouštět přes skript, takže to trvá trochu delší dobu (5-10 vteřin), ale zase se mi nestalo, že by Mplayer ve fullscreenu měl problémy s překreslováním + upscalování mu jde na jedničku 
Vidíte to, jak vidím Adobe, tak si hned vybavím Flash. Reader nepoužívám už delší dobu, místo něj mi bohatě stačí Evince (daně ale neřeším). Youtube řeším vlastní modifikací skriptu z http://wiki.multimedia.cx/index.php?title=MPlayer_youtube_script
Vidíte to, jak vidím Adobe, tak si hned vybavím Flash.Já spíš Photoshop. Flash býval původně Macromedia Flash, k Adobe se dostal až později.