V březnu byla oznámena spolupráce GrapheneOS s Motorolou. Nejnovější vlajka Motorola Signature 27 je první Motorola s oficiální podporou GrapheneOS. GrapheneOS (Wikpedie) je varianta Androidu zaměřující se na bezpečnost a soukromí.
Omarchy (Wikipedie) je linuxová distribuce s dlaždicovým správcem oken Hyprland. Založena je na Arch Linuxu. Vydána byla v nové verzi 4.5.0. Nově také pro Apple Silicon, konkrétně pro M1/M2/M3/Neo MacBooky.
Byla vydána nová stabilní verze 8.3 webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 156 s bezpečnostními opravami z Chromia 157. Přehled novinek i s náhledy v příspěvku na blogu.
Multimediální přehrávač mpv byl vydán ve verzi 0.42.0. Jde o větší balík změn po bezmála roce. Mimo jiné se lépe integruje s Waylandem nebo rozšiřuje podporu DVD/Blu-ray, např. umožňuje přehrávat rovnou obrazy médií (soubory iso).
Desktopové prostředí LXQt (Lightweight Qt Desktop Environment, Wikipedie) vzniklé sloučením projektů Razor-qt a LXDE bylo vydáno ve verzi 2.5.0. Přehled novinek v poznámkách k vydání.
Byla vydána (𝕏) nová verze 8.0 LTS open source monitorovacího systému Zabbix (Wikipedie). Přehled novinek v oznámení na webu, v poznámkách k vydání a v aktualizované dokumentaci.
Byla vydána verze R14.1.7 desktopového prostředí Trinity Desktop Environment (TDE, fork KDE 3.5, Wikipedie). Přehled novinek v poznámkách k vydání, podrobnosti v seznamu změn.
Bazzite (Wikipedie), tj. linuxová distribuce vycházející z Fedora Linuxu a optimalizována pro hraní počítačových her, byla vydána ve verzi 45. S Open Gaming Collective (OGC) jádrem a novým Easy Anti-Cheatem pro Linux (EAC Linux v2).
MikroTik zveřejnil vlastní bezpečnostní upozornění potvrzující, že zranitelnost linuxového jádra postihuje také RouterOS 7. Jde o use-after-free při zpracování IPv4 TCP spojení s IP options. Zranitelnost se týká provozu směřujícího na TCP službu samotného routeru, nikoli paketů, které router pouze přeposílá. Opraveno v long-term od 7.24.6, v stable od 7.25.1 a devel od 7.26beta5.
debian + cron - co dělám špatně?
To první.
Takový klasický ubožáček, který se nezmůže ani na argumentaci, ani na slušnou mluvu. 
Ale no tak, nezapomeň si vzít léky, třeba to zítra bude lepší. Jenže třeba taky ne. Jo, tak už to chodí.
Sice ne argumentů, ale aspoň dobrých rad. 
Drobný pohled do historie napoví. Za víc než desetiletí se mnoho nezměnilo. Z druhého drobného pohledu do historie pořádně zamrazí. Na celém tom ekosystému založeném na správě donekonečna patchovaných fosilních balíčků lidmi s blíže neurčenou kvalifikací (ochota není kvalifikace — buď víš přesně, co děláš, nebo vanilla is your friend) se od té doby nezměnilo prakticky nic.
No a pak přichází na řadu otázka použitelnosti Debianu v praxi, pro vývoj čehokoliv. V dobách mého akademického „působení“ (negativního, samozřejmě) jsem spravoval delší benchmark, který spouštěl CLBG na různých systémech (no, většinou Intel a Power7). Na jaké doméně je to hostované? Ironie, že ano! Nebylo to až tak triviální, že se to rovnou stáhne a spustí; benchmarky se různě upravovaly a v projektu šlo o zprovoznění benchmarků v dynamických jazycích v implementacích těch jazyků nad JVM. Takže Jython, JRuby, Clojure, Groovy a (méně dynamická) Scala atd.
Tohle^^^ vyžaduje běžný aktuální systém, aby se to dalo zprovoznit, včetně potřebných závislostí. Fedora: Pohoda, out-of-the-box. Arch: Jo, jasně, pohoda. (No, Power7 ale jaksi nebyl.) Tumbleweed: Taky to jde. Debian a Ubuntu: Apokalypsa. Všechno zastaralé, půlka potřebných knihoven (pro jazyky i pro pozdější vyhodnocení dat) se nepřeloží / nespustí atd.
Říkám si: To snad není možné! Tohle pracoviště má Ubuntu servery. Tak jak se s tím vyrovnalo?! Jo, „jednoduše“. Uživatelé měli speciální nastavení $PATH a ve svých domovských adresářích měli podadresáře bin/, lib/ atd., s manuálně nainstalovanými a přeloženými (kousek po kousku) aktuálními (skoro) binárkami a knihovnami, aby mohli vůbec spouštět věci, které denně potřebovali. (!!!) Tak takhle vypadá peklo. (A ano, měli to pěkně synchronizované mezi Debianem a Ubuntu, protože rsync bylo možná to jediné, co v tom prostředí neselhalo.)
Jiný projekt: Správa několika LXC a KVM strojů na fyzickém serveru, měření výkonnosti za spousty různých okolností. Fedora + Arch: Perfektní podpora virt-managera, vzájemně kompatibilní, protokol Spice, všechno jako hodinky. Ubuntu + Debian: Půl roku starý kernelový bug způsobující naprostou nepoužitelnost dat o vytížení procesoru v KVM, LXC raději nezkoušet, rozbité, naprostá absence Spice protokolu (a kdepak, příslušný balíček se na tom nepřeloží, jako ostatně většina aktuálního softwaru), nutnost aplikovat asi tak 10 hnusných tweaků, aby se dala vůbec normálně spustit virtuální mašina… Zase voser, zase zoufalství.
Tolik tedy k tomu Debianu (a derivátům založeným na podobné ideologii). Vše výše popsané je sice dávná minulost (2013) a třeba už něco z toho funguje, ale jak tak čtu dotazy zklamaných uživatelů Debianu (a derivátů), moc se toho nezměnilo.
Citation needed.
No to víš, mně jakožto asexuálovi určitě někdo přebral hypotetickou „přítelkyni“. A teď ještě tu o Červené karkulce a sedmeru krkavců.
Byl to ten maintainer, který zprasil OpenSSL, aby mělo 32768 „náhodných“ klíčů? Nebo ten, který chtěl, aby byl Debian „sexy again“, ale stal se pravý opak?
Ty zase někoho, s kým nesouhlasíš, pošleš rovnou do piče. Není spíš tohle hysterický záchvat?
Mazda a Toyota jsou hmotné objekty, které většinou mají nějakou finanční hodnotu a jejich výměna není triviální. Distribuce Linuxu se s auty nedají takhle srovnávat. Když nějaká „nestartuje“, není od věci zkusit jinou.
Přechod z 32b na 64b je use case, který se vyskytl asi tak jednou za uherské desetiletí a dnes už se moc nevyskytuje. V minulém desetiletí bylo určitě plus, když to balíčkovací systém podporoval, ale dnes už bych v tom výhodu neviděl. 
Nevím, jestli to Fedora umí. Asi ne. Osobně jsem 32b–>64b migraci bez reinstalace dělal jenom na Archu a šlo to v pohodě. Ale nebyla na to žádná přímá podpora v balíčkovacím systému, takže to vyžadovalo pár triků.
Otázka je, vůči čemu teď Linux stavíš do kontrastu. Vím o pár systémech, kde toho nefunguje mnohem víc než nějaký cron, ale vybrat si tam nemůžeš nic a opravit to taky nejde, protože je to třeba closed-source. Mít možnost vybrat si, co (ne)funguje, není k zahození.
Musí to opravdu nutně být cron, mimochodem? Existují i novější metody, lépe integrované se zbytkem systému. Pokud tedy člověk není anti-systemd fanatik…
Tiskni
Sdílej:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
30.11.2016 12:48
29.11.2016 18:58