Společnost Volla Systeme stojící za telefony Volla spustila na Kickstarteru kampaň na podporu tabletu Volla Tablet s Volla OS nebo Ubuntu Touch.
Společnost Boston Dynamics oznámila, že humanoidní hydraulický robot HD Atlas šel do důchodu (YouTube). Nastupuje nová vylepšená elektrická varianta (YouTube).
Desktopové prostředí LXQt (Lightweight Qt Desktop Environment, Wikipedie) vzniklé sloučením projektů Razor-qt a LXDE bylo vydáno ve verzi 2.0.0. Přehled novinek v poznámkách k vydání.
Nejvyšší soud podpořil novináře Českého rozhlasu. Nařídil otevřít spor o uchovávání údajů o komunikaci (data retention). Uvedl, že stát odpovídá za porušení práva EU, pokud neprovede řádnou transpozici příslušné směrnice do vnitrostátního práva.
Minulý týden proběhl u CZ.NIC veřejný test aukcí domén. Včera bylo publikováno vyhodnocení a hlavní výstupy tohoto testu.
Byla vydána nová verze 3.5.0 svobodné implementace protokolu RDP (Remote Desktop Protocol) a RDP klienta FreeRDP. Přehled novinek v ChangeLogu. Opraveno bylo 6 bezpečnostních chyb (CVE-2024-32039, CVE-2024-32040, CVE-2024-32041, CVE-2024-32458, CVE-2024-32459 a CVE-2024-32460).
Google Chrome 124 byl prohlášen za stabilní. Nejnovější stabilní verze 124.0.6367.60 přináší řadu oprav a vylepšení (YouTube). Podrobný přehled v poznámkách k vydání. Opraveno bylo 22 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Byla vydána nová verze 9.3 z Debianu vycházející linuxové distribuce DietPi pro (nejenom) jednodeskové počítače. Přehled novinek v poznámkách k vydání. Novinkou je vlastní repozitář DietPi APT.
Byl vydán Mozilla Firefox 125.0.1, první verze z nové řady 125. Přehled novinek v poznámkách k vydání, poznámkách k vydání pro firmy a na stránce věnované vývojářům. Vypíchnout lze podporu kodeku AV1 v Encrypted Media Extensions (EME). Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 125.0.1 je již k dispozici také na Flathubu a Snapcraftu.
Valkey, tj. svobodný fork již nesvobodného Redisu, byl vydán v první stabilní verzi 7.2.5.
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.