Byla vydána (𝕏) lednová aktualizace aneb nová verze 1.97 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a animovanými gify v poznámkách k vydání. Ve verzi 1.97 vyšlo také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
Nedávno se povedlo do pdf souborů vložit Tetris a DOOM a po otevření příslušného pdf souboru v na Chromiu založeném webovém prohlížeči vybranou hru přímo v pdf spustit. LinuxPDF ukazuje, že do pdf lze vložit také RISC-V emulátor a rozběhnout Linux.
Kancelářský balík LibreOffice byl vydán ve verzi 25.2. Podrobnosti v poznámkách k vydání.
Byla vydána nová stabilní major verze 24.10 linuxové distribuce primárně určené pro routery a vestavěné systémy OpenWrt (Wikipedie). Jedná se o nástupce předchozí major verze 23.05. Přehled novinek v poznámkách k vydání. Podporováno je více než 1970 zařízení. Samozřejmě včetně OpenWrt One. Linux byl povýšen z verze 5.15 na verzi 6.6.
Byla vydána nová verze 6.12 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Přináší důležité bezpečnostní opravy díky bezpečnostnímu auditu od společností Radically Open Security. Tor Browser byl povýšen na verzi 14.0.5. Thunderbird na verzi 128.6.0. Další změny v příslušném seznamu.
Databáze DuckDB (Wikipedie) byla vydána ve verzi 1.2.0. S kódovým názvem Histrionicus (kačka strakatá). Z novinek lze vypíchnout, že například 🦆 může být nově použita jako vícebajtový oddělovač sloupců. 😂
Google Chrome 133 byl prohlášen za stabilní. Nejnovější stabilní verze 133.0.6943.53 přináší řadu novinek z hlediska uživatelů i vývojářů. Podrobný přehled v poznámkách k vydání. Opraveno bylo 12 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Novinky v Knot Resolver 6: ochrana před DoS útoky – technické řešení, aktuální příspěvek na blogu zaměstnanců CZ.NIC.
Bylo publikováno jednoduché srovnání paměťové náročnosti linuxových desktopů (1. část, 2. část). Stejné testovací prostředí bylo nastaveno pomocí virtenv, Xephyr a LXC. Před spuštěním a po naběhnutí správce oken nebo desktopového prostředí byl spuštěn příkaz free. Nejméně náročným byl správce oken wm2 (0,7 MB). Nejnáročnější bylo KDE (201 MB). Pořadí: wm2, dwm, Ratpoison, JWM, i3, Blackbox, IceWM, Openbox, Window Maker, awesome, FVWM, Fluxbox, E17, LXDE, XFCE, Razor-qt, Gnome 3, Unity a KDE.
Tiskni
Sdílej:
total used free shared buffers cached Mem: 4002208 1618008 2384200 0 66176 371728 -/+ buffers/cache: 1180104 2822104 Swap: 8388604 0 8388604a toto, keď sa ten program ukončí
total used free shared buffers cached Mem: 4002208 1600888 2401320 0 66160 370736 -/+ buffers/cache: 1163992 2838216 Swap: 8388604 0 8388604(niekoľko krát som ho spustil/ukončil, aby sa minimalizoval vplyv iných programov na použitú pamäť) Čiže len pavucontrol potrebuje 16MB a to mám starú verziu, ktorej stačí Gtk+2, novšia verzia by potrebovala pamäte ešte viac (pretože by to bola jediná spustená aplikácia vyžadujúca Gtk+3).
total used free shared buffers cached Mem: 508000 484256 23744 0 23492 230148 -/+ buffers/cache: 230616 277384 Swap: 4369404 2180 4367224
člověk s 2x2GB moduly a člověk s 2x8GB moduly v notebooku jsou většinou lidé s paměťovými čipy generace vzdálenými. spotřeba paměťových modulů v podstatě nijak neroste s kapacitouV tom uz se nase metodika lisi, uvazoval jsem o stejne generaci. Pred rokem jsem to meril pro 8GB, pouzita metodika je popsana zde, novejsi cipy, cca 1W na 4GB.
Sublime TextemPlacena binarni hrouda? Navic to nejlepe chodi na OS X.
Unable to run package setup: Failed to load module Traceback (most recent call last): File "./PackageSetup.py", line 3, in <module> from __future__ import with_statement ImportError: No module named __future__Asi takhle. Musel bych to nějak ošklivě obcházet (známý workaround zahrnuje kopírování půlky knihoven Pythonu do adresáře s tím editorem).
This bug is caused by Sublime Text not detecting the path to the core Python libs its scripts depend on. You can workaround this by copying all those libs into the root folder of Sublime Text. Typically you'll find them in the /usr/lib/python2.6 or /usr/lib/python on the *nix systems (MacOS X too). Also you'll find them zipped in the "<Sublime Text>/lib/python26.zip" but this doesn't work always.sauce
Sublime Text používa vlastnú kópiu python 2.6, ktorá je priamo v tom programe a knižnice sú v lib/python26.zipDuplikace systemovych knihoven je obecne prvni krok k problemum, ale u ST3 je to reseni jinych jeste horsich problemu. ST3 alepson spousti pluginy mimo hlavni process a tak to hned pri prvnich problemech neslitne.
no .. používám KDE4 (opensuse 12.1) na notesu // celeron 1,6GHz, 768MB ram // a je o normálně použitelnéTohle moc nechápu, jak může fungovat. Možná mám nějaký problém u mě na stroji. Mam Laptop s dual core pentiem a 2GB RAM a všechno v KDE4 příšerně trvá. Zejména cokoli, co dělá plasma, takže např. zobrazit odhlašovací / vypínací okýnko trvá někdy příšerně dlouho. To samý třeba screen locker, ten je taky neskutečně pomalej. Ale i další non-plasma věci jsou pomalý, třeba ten dolphin, co jsem zmiňoval. Fakt nevim, jak to lidi dělaj, že jim KDE4 běží svižně. Přitom kraviny jako Akonadi nebo Nepomuk už jsem dávno vyházel...
Fakt nevim, jak to lidi dělaj, že jim KDE4 běží svižně. Přitom kraviny jako Akonadi nebo Nepomuk už jsem dávno vyházel...Nedělaj to nijak. Mají štěstí na HW. Patřím také mezi ty šťastné se svým notebookem – v práci máme stolní počítač, který má tabulkově prakticky shodné parametry, stejnou grafiku od Intelu, natáhnul jsem na něj kopii systému ze svého notebooku a KDE 4 tam běhá (objektivně) znatelně pomaleji. Do očí bijící je například Adobe Reader. Doma mi nastartuje asi za sekundu, v práci asi za půl minuty… Ostatní aplikace tak brutální rozdíly neposkytují, ale také je to znatelné.
Tak s měřením by mi to souhlasilo, i když se mi zdá že kde bere ještě o trochu mín. na 32bit slackwaru se dostanu po stpuštění total někde kolem 180MB komplet system tak se 2 widgety.. ale to je starší 4.5.5.
Na novějším Slackware 14 64-bit s KDE 4.8.5 a třemi widgety cca 260MB komplet.
Sleduji zvyšující se paměťové nároky s novými verzemi ale je to nárůst jen v jednotkách % . Nevím jestli je to distribucí, ale se slackem jsem se vždycky vlezl do 768 při práci, luxus je mít v kompu 1GB, ted tam mám 1,5 a je to dobré na cachování, ale že by byla pamět využita jinak, to se říct nedá.
total used free shared buffers cached
Mem: 6925 6654 270 0 45 3362
-/+ buffers/cache: 3247 3678
Swap: 8307 1 8305
total used free shared buffers cached
Mem: 6925 6654 270 0 45 3362
-/+ buffers/cache: 3247 3678
Swap: 8307 1 8305
free
nebo z free -m
?
# machinfo | grep Memory Memory: 229204 MB (223.83 GB) # swapinfo -tm | grep -v dev Mb Mb Mb PCT START/ Mb TYPE AVAIL USED FREE USED LIMIT RESERVE PRI NAME reserve - 95235 -95235 memory 218010 137237 80773 63% total 328570 232472 96078 71% - 0 -... a teraz vazne. Myslim, ze mi da viac ludi za pravdu, ze taketo testy nemaju velku vypovednu hodnotu. Vzdy je to bud, alebo. Bud je app narocna na pamat, ale pritom menej na ine "zdroje", alebo sa snazi pouzivat co najmenej pamate, ale na ukor inych "zdrojov". Teraz samozrejme neporovnavam VM takmer bez dekoracii s niecim, co je viacmenej omalovanka :) ale rovnake typy pocitacovych uloh.