Příspěvky

526

Server / Re:Jak zjistit reálný výkon CPU u VPS?

« kdy: 29. 01. 2020, 15:31:21 »

Na jednoduché testy používám sysbench. Jinak při znalosti architektury budete vědět, kolik vlákny hostitelský CPU disponuje, ne? Každá virtualizační technologie má jiné možnosti omezení. Správnost nastavení ověříte pomocí testů a monitoringem reálného provozu. To samé budete muset řešit s IO zátěží a pamětí. To téma je dost obsáhlé, koukněte na nějaké přednášky od Pavla Šnajdra z VpsFree.

527

Vývoj / Re:LXD nebo Docker

« kdy: 26. 01. 2020, 13:37:55 »

A proč ne LXD? Docker má připravené image a podporu pro návaznosti v procesu vývoje, to je jasné, ale jinak?

528

Server / Re:Server pro malou firmu

« kdy: 25. 01. 2020, 11:15:48 »

(...)

Pokud by se to postavilo na nějakém generickém "file serveru" nebo httpd. apod, a ten software by flushoval přijatá data na disk po 1500B, točivý disk by nestíhal seekovat. Laděním write-backu v blokové vrstvě to moc dohnat nejde (leda by se úplně ignorovaly bariérové operace) a nekonečný stabilní stream není řešitelný ani block-layer flash cache (protože tato nedostane šanci "si vydechnout" a protože write-mostly náklon). Jestli je to pod Windows nebo na Linuxu je mně osobně buřt, důležitý je funkční výsledek a pachatel=správce po ruce ;-)

Nepomohla by bcache?

529

Desktop / Re:Notifikátor docházející paměti

« kdy: 25. 01. 2020, 11:01:02 »

Možná bych zapátral, zda by nepomohla zram? Viz https://cs.wikipedia.org/wiki/ZRam

530

Server / Re:Přenos velkého množství dat po síti

« kdy: 24. 01. 2020, 18:34:39 »

Ondrej Nemecek

Tak jak jsem ten prikaz napsal, tak jej pouzivam. Zalohuji prez to prubezne. Pokud je v cilovem miste slozka prenesena castecne, s timto prikazem se prenese, jen to co tam jeste neni (a ve zdroji a cili se overi kontrolni soucty). Takze pri vypadku pripojeni-zdroje-cile to nejde od znova cela slozka. Ale pokud je vypadek v prubehu jednoho velkeho souboru, tak ten soubor musi jet cely znova, jen konkretni soubor ale.

Ale z mych zkusenosti, prikaz tak jak jsem napsal ja, podle kontrolnich souctu - kdyz v cili a zdroji je nejaky velky soubor, co se lisi cil a zdroj jen v nekterych blocich, ktere jsou odlisne (ani nevim, jak jsou ty bloky velke). To uz je u souboru par GB velkych znat. Ale kdyz spadne sit v prubehu prenosu velkeho souboru, musi jet ten soubor cely znova, tak jak jsem ten prikaz napsal ja.

-partial-dir=DIR resp. -partial jsem nikdy nezkousel. To pomuze i na konkretni soubor v pripade vypadku site ?

Taky nevim, jestli je bezpecne aktualizovat v souboru cilovem (velkem) jen nektere bloky. rsync pustim po dokonceni prenosu znova, s -avhc mi to spocte kontrolni soucty, ktere jsou ve zdroji a cili stejne, takze po siti jdou jen ty kontrolni souctu, je li zdoj a cil stejny a vse je OK. Jake je riziko chyby pri prenosu i s -avhc na zdroji a cili, to nevim,s jakou pravdepodobnosti muze nastat bit-flip, tusim jednou za 100-1000 TB ? Neco podobneho se tu tusim resilo pred rokem nebo tak neco. Kdyz je chyba v archivu komprimovanem, muze to odrovnat cely archiv. Takze pak moznst zdroj a cil porovnat jinym programem a kontrolnim souctem.

Žiju v přesvědčení, že se při partial naváže přenos změněných bloků tam, kde skončil. Pokud například v určitém souboru přibylo ve zdrojovém souboru na konci 1GB dat a při synchronizaci se jich přeneslo 900MB ale pak se spojení rozpadlo, tak se při volbě partial u následné synchronizace přenese již jen zbývajících 100MB a synchronizace se dokončí tj. oněch 1GB dat připojí k souboru v cíli. Přiznám se, že jsem to podrobně nestudoval, chtěl jsem spíš upozornit na tu volbu (u malých souborů je celkem zbytečná). Adreář s partial daty se dá nastavit ručně, aby nevadil v cílovém umístění, pokud se  toto umístění dále nějak zpracovává. Kdyžtak mě někdo doplňte nebo opravte...

531

Server / Re:Přenos velkého množství dat po síti

« kdy: 22. 01. 2020, 13:45:29 »

Při použití rsync se může hodit volba, aby zachoval částečně přenesená data - lze pak navázat i při výpadku připojení, což při velkých souborech ušetří čas. Jde o volby --partial případně --partial-dir=DIR Nebo, jak už tu někdo psal, ta data přenášet na úrovni souborového systému (některé souborové systémy umí synchronizovat po síti nebo po síti posílat snapshoty).

532

Studium a uplatnění / Re:Nápad na bakalářskou práci se Spring

« kdy: 22. 01. 2020, 13:42:00 »

Též gratuluji Bude to někde dostupné? Mohlo by se to někomu hodit pokud bude číst toto vlákno.

533

Server / Re:Skupinový e-mail pro potřeby SVJ

« kdy: 16. 01. 2020, 18:29:52 »

Běžné přeposílání u poskytovatele má občas problém s počtem příjemců.

OVH.com má mailing listy zdarma včetně API (pokud u nich máte maily a doménu), ale je to celkem nespolehlivá firma. 

Dále má mailing listy zdarma Google, pokud se registrujete jako neziskovka (a doložíte příslušné doklady o subjektu).

Seznam také nabízí email na vlastní doméně a má též skupinové adresy (nepoužívám).

534

Server / Re:Fotogalerie pro vlastní NAS

« kdy: 14. 01. 2020, 23:10:12 »

Vypada dobre. Vyzkousim. Mam NAS postaveny na Atomu a obavam se, ze Java aplikace nepojede uplne dobre (kdysi jsem zkousel playstation media server a ten jel strasne narozdil od minidlna, ktere slape jak hodinky). Kazdopadne jdu testnout.

Nejlépe vyzkoušet. Jde o to jaká Atom tam máte, kolik máte RAM a taky kolik těch fotek chcete spravovat. Nějaké výkonnostní charakteristiky uvádějí tady http://wiki.picapport.de/display/PIC/PicApport+Installationshandbuch Mají tam uveden i QNAP a něco s J3355 a J1900. Rozběhl jsem to i na Banana Pi M1 (A20 1GHz ARM CPU a 1GB RAM), ale bylo to pochopitelně pomalejší.

535

Server / Re:Fotogalerie pro vlastní NAS

« kdy: 13. 01. 2020, 22:58:49 »

Provozuji https://www.picapport.de/de/index.php a je to dost použitelné. Je to v javě - stáhnete .jar soubor a ten spustíte na NAS. Pokud tam máte více http serverů, tak si na apache nebo nginx nastavíte proxy. Nebo to můžete provozovat na jiném portu, to už je na vás. Vzhledem k jednoduchosti instalace doporučuji vyzkoušet. Fotky to načítá z adresáře a indexuje. Používám na VPS a fotky tam nahrávám WinSCP/ssh.

536

Hardware / Re:Osvětlení domu/bytu na stejnosměrný proud

« kdy: 10. 01. 2020, 18:18:54 »

Osobně by mi nejvíce vyhovovala nějaká stavebnice, kde si člověk může světlo průběžně upravovat. Něco jako jsou ty konzole ve výstavních síních. Použití prostoru se časem mění a s ním by mělo být možné měnit i osvětlení. Klasická svítidla na E27 žárovky jsou z tohoto pohledu asi nejhorší varianta.

Nic hotového za rozumný peníz jsem ale nenašel, tak jsem to zbastlil sám - rozvod mám 220V (starý RD), pak  mám měnič na stropě blízko osvětlení a poblíž něho na hliníkové konzoli (vlastní výroba) měděným drátem přidrátováno vícero 6W LED na 12V. Funguje to dobře a umožňuje to doplnit časem i nějakou tu stmívací logiku, měnit LED jednotlivě a také je mírně směrovat. Hezká stínidla se dají nakašírovat z papíru a natáhnout na kostru z drátu, vypadá to pak luxusně a dá se to udělat na koleně - možnost, jak k tématu přistoupit kreativně. Zkuste vyhledat homemade paperlamp (umělečtější kousky třeba ambientart.com) nebo ještě stylověji  owlpaperlamps.com/product/emperor-penguin/ Chce to celé chytit na nějaké dřevěnou konzoli, pak se ti dá průběžně upravovat. Nebo na chalupě ideálně na trám :-)

Rozvod 12V to neřeší, to je pravda, každopádně je ten úbytek napětí při více metrech už znatelný, takže rozvádět 12V po celém domě si moc nedokážu představit, pokud teda nemá jít jen o malé orientační blikátko...

537

Vývoj / Re:Rýchly vývoj administračného rozhrania

« kdy: 07. 01. 2020, 14:57:45 »

Pro čistou databázi lze použít třeba adminer ve verzi Editor - https://www.adminer.org/cs/editor/

Můžete taky použít nějaký domain-driven framework. Administrační rozhraní se odvozuje z entit, které mohou být mapované na databázi. Pro javu https://www.openxava.org/ https://isis.apache.org/ nebo http://docs.brightspot.com/dari/overview/index.html

IMHO by mohla být v dané oblasti situace lepší, jsou to buď příliš jednoduché nástroje nebo zase poměrně molochoidní věci.

538

Windows a jiné systémy / Re:Linux a v něm běžící virtuál s Windows

« kdy: 02. 01. 2020, 17:18:53 »

Rychlosti SPICE jsem myslel spusteni qemu-system-... s grafickym oknem (to predpokladam pres SPICE nebezi) a potom SPICE klienta.

Jak jsem psal, nikdy jsem si nevšiml nějaké rozdílu v rychlosti reakce GUI qemu okna vs. spice klienta. Qemu-okno je moc jednoduché takže je lepší Spice klient, který nabízí např. funkce USB-redir přímo z menu. Když vypneš Spice klienta, tak ti VM stále běží, ale když vypneš Qemu-okno, tak se VM natvrdo killne.

Při použití virt-managera se VM neukončuje, lze se opět připojit a VM zobrazit v původním stavu. Připojení se provede buď z virt-managera nebo pomocí virt-viewera (ten umí pouze zobrazit). Doporučuju si to celou virtualizaci vyzkoušet pomocí virt-managera, je to univerzální nástroj nejen pro qemu-kvm a to GUI dá poměrně dobrou představu o možnostech (i když není zas tak úplně intuitivní).

539

Windows a jiné systémy / Re:Linux a v něm běžící virtuál s Windows

« kdy: 02. 01. 2020, 16:11:38 »

Podle mě virt-manager používá interně spice, takže v rychlosti rozdíl není, běžné kancelářské aplikace běží dostatečně ryhcle.  Nejlepší je si to vyzkoušet. Qemu lze skriptovat přes monitor např. z virsh. Chce to dost RAM a SSD, jinak budete čekat na diskové operace.

540

Windows a jiné systémy / Re:Linux a v něm běžící virtuál s Windows

« kdy: 01. 01. 2020, 19:17:10 »

...

Rad bych ten fullscreen nejak sikovne prepinatelny do Xek. Dva monitory taky nechci, rad bych to mel vse na jednom.
...
Mit datovy disk ve Windows jako qcow na ext4 nechci, potrebuju to skutecne jako NTFS partition, aby to napr. bylo mozne pripojit do jine Windows masiny, nebo nabootovat ty nahradni fyzicke Windows ktere na ext4/qcow2 nikdy neuvidi. Instalace Win10 jako takova v qcow2 muze byt, data ne.

Celkem v tom nevidím problém, v podstatě jde o výchozí nastavení a po instalaci pak lze připojit ten datový NTFS disk. Akorát ten NTFS disk bude moci využívat jen jeden OS v jednom okamžiku, což Vás ale asi nepřekvapí. Jinými slovy stačí vše naklikat ve virt-manager. Ve výchozím stavu je virtualizovaný OS v okně, lze ale snando přepnout do fullscreen.