Omarchy je linuxová distribuce s dlaždicovým správcem oken Hyprland. Založena je na Arch Linuxu. Vydána byla v nové verzi 3.7.0 - The Gaming Edition. Z novinek lze vypíchnout příkaz omarchy a celou řadu herních možností.
CyberChef byl vydán v nové major verzi 11. Přehled novinek v Changelogu. CyberChef je webová aplikace pro analýzu dat a jejich kódování a dekódování, šifrování a dešifrování, kompresi a dekompresi, atd. Často je využívaná při kybernetických cvičeních a CTF (Capture the Flag).
Byla vydána nová verze 2.4.67 svobodného multiplatformního webového serveru Apache (httpd). Řešeno je mimo jiné 11 zranitelností.
Brush (Bo(u)rn(e) RUsty SHell) je v Rustu napsaný shell kompatibilní s Bash (Bourne Again SHell). Vydána byla verze 0.4.0.
Google zveřejnil seznam 1 141 projektů (vývojářů) od 184 organizací přijatých do letošního, již dvaadvacátého, Google Summer of Code. Přihlášeno bylo celkově 23 371 projektů od 15 245 vývojářů ze 131 zemí.
Na čem pracovali vývojáři GNOME a KDE Plasma minulý týden? Pravidelný přehled novinek v Týden v GNOME a Týden v KDE Plasma.
Open source počítačová hra na hrdiny NetHack (Wikipedie, GitHub) byla vydána v nové verzi 5.0.0. První verze této hry byla vydána v roce 1987.
Evropská komise naléhavě vyzvala členské státy EU, aby kvůli ochraně nezletilých na internetu urychlily zavádění unijní aplikace pro ověřování věku a zajistily její dostupnost do konce roku. Členské státy mohou zavést aplikaci EU pro ověřování věku jako samostatnou aplikaci nebo ji integrovat do takzvané evropské peněženky digitální identity.
Richard Biener oznámil vydání verze 16.1 (16.1.0) kolekce kompilátorů pro různé programovací jazyky GCC (GNU Compiler Collection). Jedná se o první stabilní verzi řady 16. Přehled změn, nových vlastností a oprav a aktualizovaná dokumentace na stránkách projektu. Některé zdrojové kódy, které bylo možné přeložit s předchozími verzemi GCC, bude nutné upravit.
Zulip Server z open source komunikační platformy Zulip (Wikipedie, GitHub) byl vydán ve verzi 12.0. Přehled novinek v příspěvku na blogu.
ip route add 0/0 dev ppp0 table 200nmcli modify "Tvoje DSL" +ipv4.routes "0/0" ipv4.route-table 200Pet minut hledani..
nmcli con modify DSL +ipv4.routes "0.0.0.0/0" ipv4.route-table 200
systemd-networkd
“beru to jako věc, která se se.e do všeho, ale nic neumí pořádně” == ”nemám tušení, která bije, a musím se tím náležitě pochlubit”
…přiznávám, že systemd-networkd jsem ještě nepoužil a neznám jej…
Manuálové stránky na Fedoře fungují? Co jsem se posledně díval, fungovaly.
Už to jde používat bez systemd-journald?
Proč by chtěl někdo používat jakýkoliv systém bez rozumně fungujícího správce logů, který má (konečně!) korektně synchronizovaný čas mezi různými zdroji logů, indexování a vyhledávání, kompresi, podpisy a ochranu před manipulací s logy, atd. atp.?
Strach z „neznámého“? Ten by byl omluvitelný možná v roce 2010. Dnes nemáme rok 2010.
Je neuvěřitelné, jak se dodnes vynořuje to uvažování z divokých devadesátých let, podle kterého je normální spustit službu z rozbitého Bash skriptu spuštěného kdovíčím a kdovíodkud, samozřejmě, že pod rootem a bez “hardeningu”, jak jinak; skript pak možná selže, možná občas ne, ale žádný problém, nikoho to nesere, hlavně když od toho nikde nebude vidět žádný stav ani log, a když náhodou jo, tak logy nebudou správně prokládané v čase vůči logům od zbytku systému, nebude to umět reagovat na uspání / probuzení / změnu nastavení sítě / jinou zásadní událost v systému…
No ale furt se najdou lidi, kteří budou tvrdit, že tenhle↑↑↑ stav věcí byl přijatelný, zatímco systemd prý jako fakt ne.
systemd FTW.
Není v tom žádný strach z neznámáho, prostě zásada držet se věcí které fungují…
Nefungují. (Přesněji řečeno: nefungovaly. Proto vznikl systemd.)
Nápodobně bash scripty - na to, co jsem potřeboval, fungovaly skvěle, jsou čitelné, univerzální a maximálně flexibilní.
Tak určitě. Dobrý vtip.
Ale třeba mne někdo přesvědčí o nějakých zásadních výhodách...
A třeba ne. Není úkolem ostatních přesvědčovat někoho o výhodách té či oné technologie. Proč by to dělali?
auth logy chcem drzat 1 rok, nejake aplikacne logy pol roka a ostatne 1 mesiac?
Rizikový nápad. Proto nic takového neřeším.
Když jeden chytrolín tuhle nedávno obešel můj SSH tarpit, nebýt systemd-journald, byl by mi zaplnil dost rychle celou kvótu logy. Nemluvě o tom, kdybych se pokoušel takové logy udržovat rok. Naštěstí systemd-journald situaci zvládl. Historii (konec řidších logů před začátkem „útoku“) jsem pak už dohledal v Btrfs snapshotech.
Což zároveň odpovídá na původní dotaz: Dokud budou logy dost řídké, budou se ve snapshotech záloh překrývat a doba jejich skladování jaksi odpovídá algoritmu pro „ředění“ a mazání zálohovacích snapshotů. Jakmile začnou být logy hustohusté (a tím pádem zároveň nepříliš zajímavé a dost rychle taky škodlivé), kus se jich (naštěstí, díky systemd-journald) do snapshotů nedostane a zbude díky tomu místo pro smysluplnější data.
journalctl.
Mimochodem, jak ze se cte ten blob kdyz jediny co funguje je vi?
O jaké situaci je tady řeč? Po apokalypse? Proč by měl fungovat jenom paskvil vi?
Počítač se nedá nabootovat z média s live systémem? Proč?
Úložiště se nedá připojit k jinému počítači? Proč?
route1=0.0.0.0/0 route1_options=table=200
Tiskni
Sdílej: