Opera 46, verze 46.0.2597.26, byla prohlášena za stabilní. Nejnovější verze tohoto webového prohlížeče je postavena na Chromiu 59. Z novinek lze zmínit například podporu APNG (Animated Portable Network Graphics). Přehled novinek pro vývojáře na blogu Dev.Opera. Oznámení o vydání zmiňuje také první televizní reklamu.
I čtenáři AbcLinuxu před dvěma lety vyplňovali dotazníky věnované Retro ThinkPadu. Nyní bylo potvrzeno, že iniciativa Retro ThinkPad je stále naživu a Lenovo připravuje speciální edici ThinkPadu jako součást oslav jeho 25. výročí.
Bylo oznámeno, že frontend a runtime programovacího jazyka D bude začleněn do kolekce kompilátorů GCC (GNU Compiler Collection). Správcem byl ustanoven Iain Buclaw.
LinuxGizmos (v dubnu loňského roku přejmenován na HackerBoards a v lednu letošního roku zpět na LinuxGizmos) zveřejnil výsledky čtenářské ankety o nejoblíbenější jednodeskový počítač (SBC) v roce 2017. Letos se vybíralo z 98 jednodeskových počítačů (Tabulky Google). Nejoblíbenějšími jednodeskovými počítači v letošním roce jsou Raspberry Pi 3 Model B, Raspberry Pi Zero W a Raspberry Pi 2 Model B.
Ne-konference jOpenSpace 2017 se koná od 13. do 15. října 2017 v hotelu Farma u Pelhřimova. Registrace účastníků je nutná. Více informací na stránkách ne-konference.
Vyšla nová verze 1.2 audio kodeku Opus, která přináší mnoho drobných optimalizací a tím i celkové vylepšení poměru bitrate/kvalita. Fullband (do 20 kHz) stereo hudba je možná již od 32 kbit/s, fullband mono řeč již od 14 kbit/s. Více informací sepsal vývojář Opusu J. M. Valin formou již tradiční demo stránky.
Na MojeFedora.cz byl zveřejněn překlad příspěvku na blogu Christiana Schallera, vedoucího desktopového týmu v Red Hatu, v němž se zabývá novinkami ve Fedoře Workstation 26 a následujících vydáních. Například již ve Fedoře 27 by se měl objevit jednotný server pro audio a video v Linuxu PipeWire. Ten byl představen před dvěma lety. Tenkrát ještě pod názvem Pinos (PulseVideo).
V KMailu byla nalezena a opravena bezpečnostní chyba CVE-2017-9604 týkající se uživatelů, již své maily podepisují a šifrují pomocí OpenPGP. Pokud uživatel KMailu při odesílání mailu zvolil možnost Odeslat později, tak byl mail odeslán nepodepsaný a v otevřeném tvaru.
Mozilla.cz zve na Mozilla meetupy v Brně a Praze. Brněnské setkání proběhne vůbec poprvé, a to tento pátek 23. 6. v Beer & Grill U Dřeváka. To pražské bude příští čtvrtek 29. 6. v Diversion Bistru.
Mám 2 servery - první velice výkonný se používá skoro nonstop a druhý je postarší ne moc výkonný. Chtěl bych udělat mirrorování dat přes síť z 1. na 2. server aby při výpadku nebylo tak velké zlo - lepší pomalý server než žádný server. Mám ideu: pomocí drbd mirrorovat disk ze serveru 1 na server 2 na zvláštní disk a pokud by server 1 padnul, tak bych server 2 restartoval do "dat ze serveru 1". Jenomže nevím jak se drbd ve skutečnosti chová. Brzdí drbd práci s diskem čekáním ne přenos po síti nebo je to asynchronní zápis? Mohu očekávat jiné problémy se stabilitou/rychlostí toho 1. rychlého serveru?
Brzdí drbd práci s diskem čekáním ne přenos po síti nebo je to asynchronní zápis?
No, jestli se na zápis čeká nebo ne definuješ vybranym protokolem:
Viz http://www.drbd.org/home/mirroring/ :
Synchronous mirroring (called protocol C in DRBD speak) is the right choice for HA clusters where you dare not lose a single transaction in case of the complete crash of the active (primary in DRBD speak) node.
Zcela souhlasím s příspěvky výše. Určitě bych jako sekundární stranu drbd nepoužíval nějakou šunku, která má pomalé diskové operace. CPU ani paměť nejsou kritické (i když musí stíhat pár set megabitů komunikace po gigabitové síťovce, ale to není tak náročné), ale průchodnost sběrnic a rychlost řadiče a disků je zcela klíčová pro celkový výkon mirroru.
Tak to asi bude drbd nepoužitelné, sekundární server (ač má gigovou síťovku), tak má pomalou sběrnici a hdparm se dostane na 70MB/s, kdežto primár je 160MB/s. Co by se dalo použít jiného? Nejedná se o přesně aktuální kopii disku, stačilo by tak starou do 10 minut nebo možná i déle, ale hlavně aby to nebrzdilo síťový provoz na serveru, který má 2 hodně užívané síťovky.
Myslím si, že by se v tvém případě by se dal akceptovat režim B (zápis je dokončen v okamžiku příjmu TCP paketu na druhé straně. Pak by zpomalený zápis na sekundátu nemusel vadit, pokud nepůjde o kontinuální zápis. Chce to vyzkoušet, jde jen o pár příkazů.
Určitě bych dal do obou serverů samostatné gigabitové síťovky a propojit extra kabelem. Skoro nic to nestojí.
rsync z cronu nebo seznamfs treba
nebo treba 1x za hodinu rdiff-backupem a budes to mit i s historii
Na rdiff, rsync a podobné nástroje pozor, v případě velkého množství souborů může synchronizace trvat třeba i půl dne 
(vlastní zkušenost)
Tiskni
Sdílej:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
