Fórum Root.cz
Hlavní témata => Distribuce => Téma založeno: Vojtax 05. 04. 2017, 15:59:44
-
Asi pred rokem jsem cetl clanek s porovnavanim rychlosti linux dister a nejak ho nemuzu najit, se mi zda ze phoronix ale proste spatne hledam. Porovnavala se rychlost bootu od power-on po login okno. Rychlost spusteni browseru - poprve, opakovane. Rychlost renderingu stranky. Rychlost filesystemu. Plus nejake matematicke benchmarky. Vse na stejnym zeleze.
Co vlastne chci? To nejrychlesji distro z roku 2016/17 pro mamu. Notas ma celkem slusny i5/8GB/SSD, tam brzda nebude. Ale jestli ji firefox nenabehne do sekundy tak je schopna to mackat 10x.. Chapete :)
Ubuntu je pro ni nepouzitelny, je to hlemyzd. A poprosim realne zkusenosti, ne co ted nekde vygooglite nebo zacnete spekulovat o gentoo s lxde ale v zivote jste to nevideli.
-
nahoď XFCE, odinstaluj zbytečný software, proveď optimalizace, nastav spuštění firefoxu po spuštění a je to. Případně existují aplikace, které se starají o přednačítání nejčastěji používaných aplikací do ram.
-
- proveď optimalizace
- existují aplikace, které se starají o přednačítání nejčastěji používaných aplikací do ram.
Muzes byt konkretnejsi v techto dvou bodech ?
-
No asi na kazdej konfiguracii to bude ine, urcite binarka ktora je prekompilovana na najnovsi Intel bude rychlejsia na skylake / kabylake. A distribucia ktora chodi dobre na starom zeleze nevyuzie potencial nového hardwaru.
Test som nerobil ale. Co som skusal rozne distribucie tak najrychlejsi mi pride arch a pri nom som aj ostal, je user friendly ako ubuntu a pritom o dost sviznejsi.
-
instalace: v efi režimu bez použití nesvobodných ovladačů pro grafiku - je to pak rychlejší
optimalizace:
10 things to do first in Xubuntu 16.04.x LTS Xenial Xerus (https://sites.google.com/site/easylinuxtipsproject/first-xubuntu), SSD: how to optimize your Solid State Drive for Linux Mint 18.1, Ubuntu 16.04 and Debian (https://sites.google.com/site/easylinuxtipsproject/ssd)
- optimalizace ssd (trim a pod)
- optimalizace v /etc/default/grub - já mám nastaveno 2 vteřiny na zobrazení grubu.
- vm.swappiness=10
pak ještě používám Remove the option 'save session' from the logout window (https://sites.google.com/site/easylinuxtipsproject/first-xubuntu#TOC-Remove-the-option-save-session-from-the-logout-window)
Načítání do mezipaměti - např.: adaptive readahead daemon (https://apps.ubuntu.com/cat/applications/preload/)
Aktuálně ho nepoužívám, ale pamatuji si, že docela fungoval.
-
- swap nepouzivam (uz snad 5 let u masin s 8+ GB RAM)
- trim na samsungy je v ubuntu default, cteni mam kolem 470MB/s, zapis kolem 420MB/s, cisla podobna jak ve windows, proste s hdparm se hrat neni treba, hw je v pohode
- adaptive readahead daemon - neco stare a opustene uz par let, asi slepa cesta
-
Xubuntu ale rozhodně hlemýžď není. Start systému na notebooku, kde mám instalováno v efi režimu je bleskový (vteřiny). Ano, readahead daemon asi nebude kompatibilní s ubuntu založeném na systemd. Jsou i jiné aplikace, preload, prelink. Taky je možné zakázat disk cache a disk cache ssl ve firefoxu, a zvětšit disk cache v ram, mohlo by fungoovat i v aktuálním vydání. http://ubuntuhandbook.org/index.php/2014/12/speed-up-firefox-ubuntu-14-04-cache-to-ram/.
Není v zásadě důvod, proč by na nových strojích optimalizované 64 bitové xubuntu mělo být pomalejší než arch atp. Osobně bych se zaměřil spíše na uživatelskou přívětivost a snadnost správy a instalace aplkací - na to mi Xubuntu vyhovuje. A je možné ho vyrobit z Ubuntu. Ale pozor, prostě je potřeba, aby bylo nainstalováno v tom efi režimu, jinak to nebude tak rychlé. Já mám starší dell latitude e6410 se 4 GB ram ddr3, SSD, nvidia grafikou a funguje velmi dobře. A zaznamenal jsem znatelný rozdíl na stejném stroji, pokud byly instalované ovladače nvidia, tak to fungovalo pomaleji.
-
Co vlastne chci? To nejrychlesji distro z roku 2016/17 pro mamu. Notas ma celkem slusny i5/8GB/SSD, tam brzda nebude. Ale jestli ji firefox nenabehne do sekundy tak je schopna to mackat 10x.. Chapete :)
Popravdě nechápu. Jak používala počítač doteď? Ze zkušenosti můžu říct toto: Trochu poštelovaný Arch i víceméně výchozí Fedora (oboje s KDE) se chovají z hlediska "uživatelské svižnosti" skoro stejně. Ubuntu spuštěné ve virtuálce na identických strojích na tom není o mnoho hůře. Zkoušel jsem to na T420 (původně i5-2540M, 8 GB RAM, SSD, později i7-2820QM, 16 GB RAM), desktopu (i5-6600K 4,3 GHz, 32 GB RAM, SSD) a výkonném "desktopu" (E5-2680v3, 32 GB RAM, SSD).
Na rychlost počítače tak, jak ji vnímá běžný uživatel má IMHO z nějakých 90 % vliv použití SSD. Prakticky jsem si to nedávno vyzkoušel na jedné stárnoucí mašině v kanceláři, ve které jsme stárnoucí mechanický disk vyměnili za Crucial MX300. I přesto, že ten stroj má tak 7 let (i7-960 a 6 GB RAM), lítají na tom Win 10, poslední Chrome a jisté komerční IDE naprosto skvěle. Opačným příkladem je notebook jednoho kamaráda, který se od mé T420 lišil jen absencí SSDčka a třeba start prohlížeče či KDEček je tam malé utrpení.
V Linuxu se dá trochu zaexperimentovat s použitím různých IO schedulerů; s SSD disky může deadline nebo noop fungovat lépe. Jednou jsem si s tím hrál ale žádného dramatického rozdílu jsem si nevšiml, chce to vyzkoušet.
-
Jadro pudla a tedy hlavni vliv na rychlost mezi distribucema bude to co vsechno je defaultne predinstalovano, hlavne demoni a sluzby. Jelikoz chci jenom desktop a par GUI aplikaci tak by nemel byt problem dohledat a vypnout services co neni treba. Ale to uz je takove to bastleni bez zaruky kde nevite co na cem zavisi a co se rozbije.
Druha vec, jak psal @beer muzou byt ovladace grafiky (ja mam jen integrovanou intel iris 6100). Ale 2D akcelerace by snad nemela byt problem s jakymkoli driverem.
Treti vec je display manager a desktop environment. Wayland je v plenkach takze zatim Xwin. No a tezkotonazni DE se stovkou libu jako KDE a Gnome tedy muzme vyloucit a zamerit se na XFCE prip. LXDE.
Stvrta vec je jak se kompilovalo. U 64bit distra nepredpokladam dramaticke rozdily v -march prepinaci, predpokladam, ze dnes se snad vsechno kompiluje s "core2" co je dobry krome intelu jak pro amd tak pro atomy.
Pata vec - kernel. No na rovinu, naposledy jsem kernel kompiloval jeste za dob RHEL5 a od ty doby na to radeji nesaham :) Ale jiste by se nasla desitka modulu co nepotrebuji, podpora kde jakeho filesystemu atd. Mozna se s tim pohram o vikendu. Nekdy -o3 dela zazraky :-)
-
2d bych se nebál, a ani 3d. U karet nvidia už obstojně funguje 3d akcelerace i na svobodných ovladačích. Jak je to s amd grafikama a ostatníma minoritníma, to nevím.
Jinak 100% souhlas s @Vojtax a @Neviditelný.
Nevím, jestli jsem měnil plánovač, ale používám aktuálně deadline, nevím, jestli tam je aktuálně autodetekce, v některých verzích jsem jí nastavoval. Každopádně deadline se dá použít na SSD i HDD, na HDD je asi lepší cfq, noop používat jen s SSD či flashdisky. Dá se na to nastavit udev, aby poznal, o jaký disk se jedná a nastavil požadovaně plánovač. Deadlinem se ale určitě nic nezkazí.
Nepotřebné služby prostě povypínat (bluetooth, apod).
-
Načítání do mezipaměti - např.: adaptive readahead daemon (https://apps.ubuntu.com/cat/applications/preload/)
Aktuálně ho nepoužívám, ale pamatuji si, že docela fungoval.
pro SSD to je spiš kontraproduktivni
-
32 bit bude urcite ryhclejsi nez 64bitovy, jestli chce odezvu okamzite nezbyva nez nevypinat ale uspavat do Ram
-
32 bit bude urcite ryhclejsi nez 64bitovy
To sotva, na serverech kde mame treba postgresql je 64bit asi o 1/3 rychlejsi nez 32bit. U firefoxu to bude zrejme obdobny. Bylo by to proti logice, je rozdil v jednom taktu spracovat 64bit dat nez 32bit v dvou taktech :)
nezbyva nez nevypinat ale uspavat do Ram
Nechci trolovat, ale tohle vubec nekdy fungovalo v linuxu? Tim fungovalo myslim fungovalo, ne ze po probuzeni nepujde wifi, zvuk a nekdy se to neprobere vubec a pomuzou jen 4 sekundy na power tlacitku.
-
Suspend to RAM používám v linuxové distribuci každý den již mnoho let.
Kdybych měl notebook pořád zapínat, bylo by to o nervy.
Žádné problémy se sítí nebo zvukem nemám, prostě zmáčknu tlačítko a za sekundu pracuji.
32bit je rychlejší a bere méně RAM, už z principu.
Srovnávej rychlost na stejném železe, s RAM do 4 GB.
32bitový postgresql s 32bitovou distribucí + 4 GB RAM x 64bitovým postgresql s 64bitovou distribucí + 4 GB RAM.
-
Otázka je nesmysl, na distribuci nezáleží (až na extrémní případy), software je ve všech stejný.
Ubuntu je pro ni nepouzitelny, je to hlemyzd.
Děláš něco špatně.
(mimochodem co třeba programy, které používáš často, nevypínat? já Firefox restartuju jednou za 14 dní, když vyleakuje moc paměti)
Nechci trolovat, ale tohle vubec nekdy fungovalo v linuxu? Tim fungovalo myslim fungovalo, ne ze po probuzeni nepujde wifi, zvuk a nekdy se to neprobere vubec a pomuzou jen 4 sekundy na power tlacitku.
Ano, samozřejmě, na všech třech mých počítačích asi tak od roku 2008.
32bit je rychlejší a bere méně RAM, už z principu.
Můžeš rozvést, kde tam vidíš ten princip? Záleží na použití, ale ve většině případů bych čekal rychlejší 64b. Jediné, co na x86_32 může pomoct, jsou kratší pointry, takže ušetříš trochu paměti a místo v cache. x86_64 oproti tomu těží z dvojnásobného počtu registrů (čtyři alespoň trochu general-purpose registry na 386 jsou vtip), nativnímu zpracování 64b čísel a vektorových instrukcí.
-
Treba v KDE kdysi slo zapnout, ze po kliknuti na ikonu aplikace poskakovala po monitoru ikona, dokud aplikace nenabehla. Jako zpetn vazby, ze ke kliku opravdu doslo, si toho vsimne snad i slepy. Treba by to stacilo, jestli tohle dnesni KDE jeste ma.
-
jeste to tu je Settings > Applications > Launch Feedback > Bauncing Cursor
-
Jadro pudla a tedy hlavni vliv na rychlost mezi distribucema bude to co vsechno je defaultne predinstalovano, hlavne demoni a sluzby. Jelikoz chci jenom desktop a par GUI aplikaci tak by nemel byt problem dohledat a vypnout services co neni treba. Ale to uz je takove to bastleni bez zaruky kde nevite co na cem zavisi a co se rozbije.
To si nemyslím. Vypínání služeb na pozadí mělo smysl v dobách, kdy měly počítače zoufale málo RAM a každý megabyte se počítal. Díval jste se, jakou máte spotřebu RAM a zátěž CPU v klidu? Tipnul bych si, že CPU se bude flákat mezi 0 - 2 % zátěže a RAM bude ze tří čtvrtin k dispozici.
Druha vec, jak psal @beer muzou byt ovladace grafiky (ja mam jen integrovanou intel iris 6100). Ale 2D akcelerace by snad nemela byt problem s jakymkoli driverem.
Pro Intelí grafiky je k dispozici je jeden ovladač, který určitě máte nainstalovaný, protože je součástí jádra a Mesy. Zde toho tedy moc nevymyslíte.
Treti vec je display manager a desktop environment. Wayland je v plenkach takze zatim Xwin. No a tezkotonazni DE se stovkou libu jako KDE a Gnome tedy muzme vyloucit a zamerit se na XFCE prip. LXDE.
Display manager výkon určitě nijak neovlivní, pracovní prostředí dost minimálně. Je možné, že třeba aplikace postavené okolo KF5 knihoven budou startovat o něco pomaleji. Naopak zrovna použití Xek místo Waylandu nějaký negativní efekt na rychlost mít může. Z jedné přednášky Daniela Stonea si pamatuji, že třeba při spuštění GEditu zabere dost času jen fetching nějakých properties od Xek. Sám bohužel desktop na Waylandu nikde naostro nemám, F25 s Gnome a experimentální podpora Waylandu v KDE mi přišly mírně svižnější, než když to běželo po Xky, když jsem to ze zvědavosti párkrát zkoušel.
Stvrta vec je jak se kompilovalo. U 64bit distra nepredpokladam dramaticke rozdily v -march prepinaci, predpokladam, ze dnes se snad vsechno kompiluje s "core2" co je dobry krome intelu jak pro amd tak pro atomy.
Arch myslím kompiluje s -march=generic, u ostatních dister nevím. Když jsem na podobné vylomeniny měl čas, kompiloval jsem si ručně třeba mplayer, ffmpeg a dalších pár kousků softwaru, co mi přišly jako výkonnostně náročnější. Teď používám zásadně distribuční verze a nepozoruji žádný rozdíl.
Pata vec - kernel. No na rovinu, naposledy jsem kernel kompiloval jeste za dob RHEL5 a od ty doby na to radeji nesaham :) Ale jiste by se nasla desitka modulu co nepotrebuji, podpora kde jakeho filesystemu atd. Mozna se s tim pohram o vikendu. Nekdy -o3 dela zazraky :-)
Dnes je v jádře skoro všechno modulární a co není potřeba, tak se nezavede. Jádro jsem si sám samozřejmě překládal také a též nemám dojem, že by to kdovíjak pomohlo.
Kdysi dávno jsem rozběhával na Celeronu 300A Gentoo. Bylo to v době, kdy tento procesor patřil spíše do muzea milníků výpočetní techniky než do pracovního stroje. Po týdnu zběsilého kompilování se všemožnými optimalizacemi jsem tam dostal KDE 3.5 a Firefox. Firefox startoval 30 vteřin, KDEčka asi minutu a půl a celé to bylo bytostně nepoužitelné. I kdybych ty KDEčka nahradil nějakým Fluxboxem, Firefoxu by to přiliš nepomohlo. O pár let později jsem měl na Athlonu 64 3000+ Gentoo, na P4E 3.2 Arch, obé s KDE 4. Gentoo baštila o něco méně paměti, nejspíš proto, že jsem USE flagy vypnul podporu pro různé blbinky. Rozhodně ale nešlo říci, že by ta Gentoo byla viditelně rychlejší.
32 bit bude urcite ryhclejsi nez 64bitovy
Tohle je absolutní blbost. Programy přeložené pro x86_64 mohou použít více registrů, do jednoho registru nacpat 2x více dat a předpokládat instrukční sadu SSE2. Na Phoronixu se to párkrát benchmarkovalo a 64bitový Linux ten 32bitový - byť jinak identický - totálně zažehlil.
-
No, ale 32bit bude rychleji startovat, protože binárky na disku i knihovny budou menší a víc se jich vleze do různých cache....
Taky ubuňtu má lowlatency kernel, což je na desktop, pro rychlou odezvu, to by se asi hodilo vyzkoušet
-
No, ale 32bit bude rychleji startovat, protože binárky na disku i knihovny budou menší a víc se jich vleze do různých cache....
Na nějakém embedded systému s minimem prostředků by to možná stálo za úvahu, na moderním PC s SSD to bude na hranici měřitelnosti.
Taky ubuňtu má lowlatency kernel, což je na desktop, pro rychlou odezvu, to by se asi hodilo vyzkoušet
Není ten lowlatency kernel myšlený spíš pro určitá konkrétní použití, např. v nahrávacím studiu, kde je nutné zajistit, aby systém obsloužil zvukovou kartu "dostatečně včas"? Tím, že bude jádro častěji spouštět task scheduler se výkon určitě nezvýší, spíš naopak. Navíc ten lowlatency kernel tuším není tickless, takže pro použití v notebooku není kvůli vyšší spotřebě energie moc vhodný.
-
32bit je rychlejší a bere méně RAM, už z principu.
Zdroj?
A předpokládám, že je řeč Linuxu a ne např. o Windows. Takže 4 bit kalkulačky jsou dle stejného principu ještě rychlejší? Co nové instrukce? Zpracování větších operandů jednou instrukcí a/nebo v jednom taktu ap.? Ne, 32 bit skutečně rychlejší není. A navíc 64 binárky jsou menší = zaberou méně RAM i když na druhou stranu, některé věci zase u 64 bit zabírají více RAM.
-
Není ten lowlatency kernel myšlený spíš pro určitá konkrétní použití, např. v nahrávacím studiu, kde je nutné zajistit, aby systém obsloužil zvukovou kartu "dostatečně včas"? Tím, že bude jádro častěji spouštět task scheduler se výkon určitě nezvýší, spíš naopak. Navíc ten lowlatency kernel tuším není tickless, takže pro použití v notebooku není kvůli vyšší spotřebě energie moc vhodný.
Hele, paní chce míň čekat, tedy menší latence. Ten lowlatency je subjektivně svižnější pro interaktivní práci. Klesne trochu přenosová rychlost na úkor latence, ale to paní asi nevadí.
Se spotřebou nevím, to v zadání nebylo. Ale není to RT kernel, takže možná tickless taky bude, musel bych se kouknout.
Za mě jednoznačně lowlatency. A amd64, i386 už asi nemá cenu. Škoda, že se nechyt x32.
-
Není ten lowlatency kernel myšlený spíš pro určitá konkrétní použití, např. v nahrávacím studiu, kde je nutné zajistit, aby systém obsloužil zvukovou kartu "dostatečně včas"? Tím, že bude jádro častěji spouštět task scheduler se výkon určitě nezvýší, spíš naopak. Navíc ten lowlatency kernel tuším není tickless, takže pro použití v notebooku není kvůli vyšší spotřebě energie moc vhodný.
Hele, paní chce míň čekat, tedy menší latence. Ten lowlatency je subjektivně svižnější pro interaktivní práci. Klesne trochu přenosová rychlost na úkor latence, ale to paní asi nevadí.
Jenomže uživatel chce méně čekat v řádu sekund až desítek sekund, rozdíl mezi lowlatency a plně preemptivním jádrem bude maximálně v řádu milisekund. Lowlatency jádro např. start Firefoxu určitě nijak viditelně neurychlí. Nechť to tazatel klidně vyzkouší, ale moc bych si od toho nesliboval...
-
64bitové procesory jsou již řadu let zcela běžné a současně zůstávají zpětně kompatibilní s těmi 32bitovými. Proto si lze vybírat variantu poměrně svobodně – samozřejmě s přihlédnutím k tomu, že dvaatřicetibitový systém je omezený z hlediska využitelného adresního prostoru (čili náročnější aplikace mohou narazit na jeho limity).
Důležitou otázkou však je, jak si varianty stojí z hlediska výkonu. Mapování velké fyzické paměti do 32bitového adresního prostoru přináší nemalou režii, na druhou stranu 64bitová adresa je dvakrát delší a pracuje se tedy s většími objemy dat. V praxi se to může projevit různě, proto stojí za to si to otestovat.
A právě takový test provedl server Phoronix. Pro porovnání posloužily dvě varianty poslední vývojové verze distribuce Ubuntu, tedy 13.10. A jak to dopadlo? Téměř ve všech testech zvítězilo 64 bitů, a to v některých případech poměrně výrazně – rozdíl činil až desítky procent. Jediným případem, kdy při dané testovací konfiguraci výrazně vedl 32bitový systém, byl Apache Benchmark.
Jen jestli to není hyperaktivita nebo neuróza, případně tremor či parkinsonova choroba.
Tip: firefox nastavit, aby se spouštěl po spuštění. A klidně minimalizovaně v liště. Pokud náhodou nějaký program na to nemá volbu, dá se použít start přes alltray. Sice desktop bude startovat asi o 1-2 vteřiny déle, ale na druhou stranu firefox apod budou připravené otevřené hned v liště.
Lowlatency kernel jsem kdysi na desktopu zkoušel, a byly s tím jen problémy.
-
To byl rok 2013, předpokládám, že dnes by si 32-bit ani neškrtl. Nehledě na to, některé programy na 32 bit ani nejsou - například google chrome.
-
tak lowlatency je uplne stejne tickless jako generic, tedy CONFIG_NO_HZ_IDLE, ale ne CONFIG_NO_HZ_FULL
rozdil je jen v CONFIG_HZ, ale to vsichni normalni maji na desktopech na 1000, tak jak je v lowlatency; 250 se hodi spis na servery
grep _HZ /boot/config-4.8.0-46-lowlatency
CONFIG_NO_HZ_COMMON=y
# CONFIG_HZ_PERIODIC is not set
CONFIG_NO_HZ_IDLE=y
# CONFIG_NO_HZ_FULL is not set
CONFIG_NO_HZ=y
# CONFIG_HZ_100 is not set
# CONFIG_HZ_250 is not set
# CONFIG_HZ_300 is not set
CONFIG_HZ_1000=y
CONFIG_HZ=1000
grep _HZ /boot/config-4.8.0-46-generic
CONFIG_NO_HZ_COMMON=y
# CONFIG_HZ_PERIODIC is not set
CONFIG_NO_HZ_IDLE=y
# CONFIG_NO_HZ_FULL is not set
CONFIG_NO_HZ=y
# CONFIG_HZ_100 is not set
CONFIG_HZ_250=y
# CONFIG_HZ_300 is not set
# CONFIG_HZ_1000 is not set
CONFIG_HZ=250
-
Debatu o 32bitech muzete rovnou ukoncit, pujde tam 64bit a hotovo. Nehlede na to, ze tam je 8GB RAM a to by 32bit system musel obchazet pres neajkou PAE berlicku co rozhodne na rychlosti neprida.
Zatim experimentuji s ruznyma distribucema ve VirtualBoxu a pokusne k tomu sem tam mamu poustim :-) Long story short - zatim vede Xubuntu 16.10, je to k neuvereni jaky je tam rozdil od Unity (at mu je zem lehka). Mrknul jsem taky na Arch a to sem se panecku ocitl v minulem tisicileti v shellu s blikajicim kurzorem :D Tak jsem pak pouzil radej Revenge verzi s klikatkem. Subjektivne je Xubuntu zivejsi ale firefox startuje o chlup pomaleji. V Archu zas desktop je o chlup linejsi, zato firefox startuje rychleji. Jeste mam v planu Fedoru s paralelnim bootovanim a kouknu taky ten low latency kernel.
Pak stopky do ruky a hodim sem cisla :)
-
Přešel jsem z různých ?buntu na Bunsenlabs s Openboxem a rychlost mě velmi mile překvapila.
-
Přešel jsem z různých ?buntu na Bunsenlabs s Openboxem a rychlost mě velmi mile překvapila.
To chápu, nedávno jsem provozoval crunchbang s openboxem na stroji, který měl 512 RAM a grafický čipem, který takových 128 mega z té ram ještě ukrajoval. A bylo to použitelné - dalo se v tom dokonce i trošku surfovat. Ale dokážeš si představit nějakou starší dámu, jak pracuje s openboxem? Leda kdyby jí naběhl po zapnutí prohlížeč.
-
[...] nedávno jsem provozoval crunchbang s openboxem na stroji, který měl 512 RAM a grafický čipem, který takových 128 mega z té ram ještě ukrajoval. A bylo to použitelné - dalo se v tom dokonce i trošku surfovat.[...]
bezi mi tu na ARM netbooku s 512MB RAM (po donastaveni, pristupne az 496M) regulerni Xubuntu ktere pri startu zabere 100MB... a je to naprosto v pohode rychle ze by me ani nenapadlo pouzit neco odlehcenejsiho ;) pri pouziti Chromium (+ uBlockOrigin + PrivacyBadger a vyladene nastaveni) se da vice surfovat, tedy nekolik az 10 zalozek, GMail, Root, Abclinuxu, CZC, Aukro, Bazos, reakce jsou porad rychle, pro zavirani listu HODNE pomuze nastavit chrome://flags/#enable-fast-unload ktere zajisti ze UI neceka az se po listu uklidi (uklid probiha nezavisle/na pozadi)...
k dotazu tazatele, Xubuntu 16.04LTS na SSD... kdyz je vice ram, tak cache prohlizece a tmp presmerovat do RAM pres tmpfs... za urciteho omezeni ktere by bylo resitelne zcastni nebo zcasti ignorovatelne se da nejvysi rychlosti pak docilit pouzitim live rezimu z ISO(upravenym, aktualizovanym) na SSD ktere se pri startu CELE nakopiruje do RAM, a pak pracuje komplet z RAM...
-
Přešel jsem z různých ?buntu na Bunsenlabs s Openboxem a rychlost mě velmi mile překvapila.
To chápu, nedávno jsem provozoval crunchbang s openboxem na stroji, který měl 512 RAM a grafický čipem, který takových 128 mega z té ram ještě ukrajoval. A bylo to použitelné - dalo se v tom dokonce i trošku surfovat. Ale dokážeš si představit nějakou starší dámu, jak pracuje s openboxem? Leda kdyby jí naběhl po zapnutí prohlížeč.
Dovedu a mám to tak u otce. Tint2 s pár ikonkama (pošta, www, libreoffice) v pruhu nahoře, několik málo počeštěných klávesových zkratek v Conky, jedna plocha a je to. K woknum se už nechce vrátit.
-
http://vectorlinux.com/
-
No neuverite jak to dopadlo. Kolega prodaval starsi MacBook Air za skvelou cenu, tak mne napadlo jej dat mame na zkousku pres vikend. A uz si jej nechala ;) Takze problem vyresen, mama je sice ted Apple ovecka ale vsechno ji to frci, je spokojena a to je to hlavni!
Horsi je, ze ted zacina brouk zrat i mou hlavu a pokukuji po Macbook Pro... ale to uz je jina story.
-
Horsi je, ze ted zacina brouk zrat i mou hlavu a pokukuji po Macbook Pro... ale to uz je jina story.
Tak furt to je plnohodnotný Unix, navíc nad Machem a s pekelně rychlým SSD - pokud nevadí cena, je to hezká hračka.