Byla vydána verze 4.0.0 programovacího jazyka Ruby (Wikipedie). S Ruby Box a ZJIT. Ruby lze vyzkoušet na webové stránce TryRuby. U příležitosti 30. narozenin, první veřejná verze Ruby 0.95 byla oznámena 21. prosince 1995, proběhl redesign webových stránek.
Všem čtenářkám a čtenářům AbcLinuxu krásné Vánoce.
Byla vydána nová verze 7.0 linuxové distribuce Parrot OS (Wikipedie). S kódovým názvem Echo. Jedná se o linuxovou distribuci založenou na Debianu a zaměřenou na penetrační testování, digitální forenzní analýzu, reverzní inženýrství, hacking, anonymitu nebo kryptografii. Přehled novinek v příspěvku na blogu.
Vývojáři postmarketOS vydali verzi 25.12 tohoto před osmi lety představeného operačního systému pro chytré telefony vycházejícího z optimalizovaného a nakonfigurovaného Alpine Linuxu s vlastními balíčky. Přehled novinek v příspěvku na blogu. Na výběr jsou 4 uživatelská rozhraní: GNOME Shell on Mobile, KDE Plasma Mobile, Phosh a Sxmo.
Byla vydána nová verze 0.41.0 multimediálního přehrávače mpv (Wikipedie) vycházejícího z přehrávačů MPlayer a mplayer2. Přehled novinek, změn a oprav na GitHubu. Požadován je FFmpeg 6.1 nebo novější a také libplacebo 6.338.2 nebo novější.
Byla vydána nová verze 5.5 (novinky) skriptovacího jazyka Lua (Wikipedie). Po pěti a půl letech od vydání verze 5.4.
Byla vydána nová verze 5.4.0 programu na úpravu digitálních fotografií darktable (Wikipedie). Z novinek lze vypíchnout vylepšenou podporu Waylandu. Nejnovější darktable by měl na Waylandu fungovat stejně dobře jako na X11.
Byla vydána beta verze Linux Mintu 22.3 s kódovým jménem Zena. Podrobnosti v přehledu novinek a poznámkách k vydání. Vypíchnout lze, že nástroj Systémová hlášení (System Reports) získal mnoho nových funkcí a byl přejmenován na Informace o systému (System Information). Linux Mint 22.3 bude podporován do roku 2029.
GNU Project Debugger aneb GDB byl vydán ve verzi 17.1. Podrobný přehled novinek v souboru NEWS.
Josef Průša oznámil zveřejnění kompletních CAD souborů rámů tiskáren Prusa CORE One a CORE One L. Nejsou vydány pod obecnou veřejnou licenci GNU ani Creative Commons ale pod novou licencí OCL neboli Open Community License. Ta nepovoluje prodávat kompletní tiskárny či remixy založené na těchto zdrojích.
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: