Svobodná historická realtimová strategie 0 A.D. (Wikipedie) byla vydána ve verzi 28 (0.28.0). Její kódový název je Boiorix. Představení novinek v poznámkách k vydání. Ke stažení také na Flathubu a Snapcraftu.
Multimediální server a user space API PipeWire (Wikipedie) poskytující PulseAudio, JACK, ALSA a GStreamer rozhraní byl vydán ve verzi 1.6.0 (Bluesky). Přehled novinek na GitLabu.
UBports, nadace a komunita kolem Ubuntu pro telefony a tablety Ubuntu Touch, vydala Ubuntu Touch 24.04-1.2 a 20.04 OTA-12.
Byla vydána (Mastodon, 𝕏) nová stabilní verze 2.0 otevřeného operačního systému pro chytré hodinky AsteroidOS (Wikipedie). Přehled novinek v oznámení o vydání a na YouTube.
WoWee je open-source klient pro MMORPG hru World of Warcraft, kompatibilní se základní verzí a rozšířeními The Burning Crusade a Wrath of the Lich King. Klient je napsaný v C++ a využívá vlastní OpenGL renderer, pro provoz vyžaduje modely, grafiku, hudbu, zvuky a další assety z originální kopie hry od Blizzardu. Zdrojový kód je na GitHubu, dostupný pod licencí MIT.
Byl představen ICT Supply Chain Security Toolbox, společný nezávazný rámec EU pro posuzování a snižování kybernetických bezpečnostních rizik v ICT dodavatelských řetězcích. Toolbox identifikuje možné rizikové scénáře ovlivňující ICT dodavatelské řetězce a na jejich podkladě nabízí koordinovaná doporučení k hodnocení a mitigaci rizik. Doporučení se dotýkají mj. podpory multi-vendor strategií a snižování závislostí na vysoce
… více »Nizozemský ministr obrany Gijs Tuinman prohlásil, že je možné stíhací letouny F-35 'jailbreaknout stejně jako iPhony', tedy upravit jejich software bez souhlasu USA nebo spolupráce s výrobcem Lockheed Martin. Tento výrok zazněl v rozhovoru na BNR Nieuwsradio, kde Tuinman naznačil, že evropské země by mohly potřebovat větší nezávislost na americké technologii. Jak by bylo jailbreak možné technicky provést pan ministr nijak nespecifikoval, nicméně je známé, že izraelské letectvo ve svých modifikovaných stíhačkách F-35 používá vlastní software.
Nové číslo časopisu Raspberry Pi zdarma ke čtení: Raspberry Pi Official Magazine 162 (pdf).
Sdružení CZ.NIC, správce české národní domény, zveřejnilo Domain Report za rok 2025 s klíčovými daty o vývoji domény .CZ. Na konci roku 2025 bylo v registru české národní domény celkem 1 515 860 s koncovkou .CZ. Průměrně bylo měsíčně zaregistrováno 16 222 domén, přičemž nejvíce registrací proběhlo v lednu (18 722) a nejméně pak v červnu (14 559). Podíl domén zabezpečených pomocí technologie DNSSEC se po několika letech stagnace výrazně
… více »Google představil telefon Pixel 10a. S funkci Satelitní SOS, která vás spojí se záchrannými složkami i v místech bez signálu Wi-Fi nebo mobilní sítě. Cena telefonu je od 13 290 Kč.
Na serverech tenhle problem nemam. Server se nainstaluje, nastavi a pak jede, dokud se nezrusi. Na notebooku mam zase relativne kratkou dobu zivotnosti distribuce, takze reinstalace cca jednou za rok to jisti. Jina otazka nastava v okamziku, kdy se ma clovek starat o desitky, pripadne stovky serveru. Pak nastupuji nastroje typu cfengine.
Psane poznamky jsem zkousel ale kam je psat?
Zkus lokální wiki (já používám klasickou mediawiki). Velmi snadno vytvoříš nový zápisek, třeba stylem co služba to článek. Můžeš vytvářet odkazy na neexistující články, tento seznam pak může sloužit i jako todo. Články to má verzované, i to se hodí. Nakonec z toho máš soukromou knowledge base. Nejhorší je se přinutit to tam poctivě psát. S tím ti to nepomůže.
Pro často měněné configy (u mě firewall) jsem si zařídil svn repositář. Pokud člověk dodržuje zásady commitu (commit by měl být co nejmenší a měl by obsahovat jednu ucelenou část, každý commit musí mít komentář), dost to pomůže udržovat pořádek v konfigu samotném.
Celé /etc denně zálohuji pomocí rsnapshot. Můžeš těch verzí mít pak třeba tisíc, spotřebované místo je minimální. Já to používám spíš jako ochranu proti nechtěnému smazání.
Zkus lokální wiki (já používám klasickou mediawiki).
Já si zase tyhle poznámky píšu do blogu – nezobrazuji je na titulní stránce, protože by toho tam bylo moc, ale dávám je pod štítek Taháky a snadno se k nim dostanu odkudkoli
A možná na ně občas zabrousí i někdo jiný. 
jak je to s mediawiki a přikládáním souborů? dají se v tom držet i ty configy? nebo ty mít v svn/git/ap? rád bych jedno řešení...
Určitě bych to držel oddělené. Stejně potřebuješ místo, kam si psát různé HOW-TO, poznámky, než se ti to dostane do krve. Hezky bod za bodem. Na toto se ti právě bude hodit ta wiki. Je to formátovaný text, vypadá to hezky, dá se to tisknout.
Do wiki lze přikládat i soubory, též jsou tam verzované. Ale jako náhrada za VCS je to nepoužitelné.
a nebo místo wiki třeba backpack (http://backpakit.com)
na to pouzivam git
-Nainstaluju cistej system.
-Nainstaluju SW.
-Kazdou zmenu konfigurace systemu i SW ukadam do root-a.
-Jednou za cas pozalohuju celou "konfiguraci".
-Kdyz se server zrusi vratim se do bodu 1 a pouziju zalohovanou konfiguraci.
-Stale dokola.
NN
/etc, /var/lib, ~/binale vzhledem k tomu, že mám podobné configy na serveru i na ntb(oboje debian) je to nepřehledné, nevím jaké změny se udály mezi jednotlivými verzemi..
Myslite komentar..do konfiguraku, nekdy.
Jake kroky?
Zalohuju pouze to co jsem sam zmenil.
NN
git pouzivam len nad /etc/ kde je asi najviac vsetkej konfiguracie.
dovody su:
- jeho repozitar je ulozeny v jednom adresari .git, narozdiel od svn, ktory si uklada uplne vsade .svn podadresare a repozitar musi byt niekde inde, tiez je rychly a cely archiv zabera ovela menej nez svn
- je mozne repozitar synchronizovat aj s nejakym inym sietovym (git remote, git push, ...) koli zalohovaniu
- vyuzivam to najma aby som vedel co kedy sa zmenilo, takze po aktualizaciach alebo zmenach vzdy zmeny commitnem (git commit), pripadne este predtym pridam nove subory do repozitara (git add .)
- mozem si robit znacky (git tag ...)
- pozriet si zmeny suborov medzi jednolivymi verziami (git diff....)
... jednoducho klasicky verzovaci system
ktory je aj jednoduchy a pride mi jednoduchsi nez svn, alebo cvs (ostatne som neskusal). pouzivam ho najma na programatorske projekty, ale aj na /etc
a ma parkrat aj zachranil ked som si rozbil nejaku konfiguraciu. skvele je ze vobec nemusim vytvarat nejake .bak, ... v ktorych po case aj tak clovek ma len bordel 
ziadna veda:
cd /etc git init git add . git commit -a -m "initial release"
viz můj komentář – musíš ochránit celé úložiště (git, mercurial…), aby k němu mohl jen root.
Tyhle 4 řádky jsou o gitu všude.
U svn mám repositář na jednom místě. Každý commit (odkudkoliv) ta data tlačí právě tam. Stačí mi zálohovat toto jedno místo. Když to někdo udělá naznačeným způsobem v gitu tak musí zálohovat tuhle /etc/.git, támhle /var/named/.git atd. Pokud totiž bude chtít mít centrální gití repos, tak musí po každém commitu udělat jestě git push.
U svn mám repositář na jednom místě.
Tohle moc nechápu – vždyť subversion přece vytváří .svn v každém adresáři – v tom se mi víc líbí hg/git, kde takový adresář je jen jeden – v rootu daného úložiště. Centrální úložiště by se dalo řešit tak, že bys ten init udělal v rootu souborového systému a složky jako /usr, /home, /tmp … bys dal do .hgignore (nevím, jak se to jmenuje v gitu) – pak by stačilo zálohovat /.hg (resp. /.git), kde by bylo všechno na jednom místě.
Jo už rozumím – je to jedna z výhod nedistribuovaných verzovacích systémů (jednodušší práce, jen commit, místo commit+push).
Toto jde u gitu udělat druhým repositářem, který se prohlásí za server. Zde je ale nutné po každém commitu u klienta udělat git push. Snad to píšu dobře, s gitem si vyloženě nerozumím.Ten push po commitu jde pohodlně udělat pomocí hooku
/etc/.git a zazálohuje do nějakého centrálního repa?
co konkrétně udělá git push? vezme třeba /etc/.git a zazálohuje do nějakého centrálního repa?
Git je distribuovaný systém správy versí. Tedy můžeš mít hlavní repositář (říkejme mu teď server), z něj si uděláš clon do /etc (tomu říkejme klient). Pokud chceš všechny commity klienta mít i na serveru musíš za každým commitem udělat i push.
To co radí kolega výše, tedy vytvoření repa v /etc není napojeno na server. Tedy ty si můžeš ukládat verze konfigů, ale smazáním /etc/ přijdeš i o ten git repositář a tedy i o veškerou historii.
Musel bys tedy pravidelně zálohovat celé /etc včetně toho repositáře.
svn pracuje jinak. Tam potřebuješ server vždy. Tedy commit v /etc ti data vždy pošle na server. Tento jeden server můžeš použít pro ukládání všeho. Konfigů, svých dokumentů, projektů do školy apod. Při smazání /etc/ pak stačí pouze udělat svn checkout. Stačí ti zálohovat jeden server.
Uživatel zničit repo svými příkazy nemůže.
Repo lze pouze zničit administrátorskými zásahy na svn serveru. Ať již klasické rm -rf, nebo nesprávným použitím svnadminu. Ale od toho jsou zálohy.
když budu mít mnoho rep, dá se jednoduše zjistit na čem sem dělal řekněme za poslední týden?
Musel bys projít všechna a zjistit cos tam kdy udělal.
Co se týče git vs svn, raději si to projdi sám. K svn je někde velmi pěkné PDF. Po oběde najdu a hodím to sem.
Když to někdo udělá naznačeným způsobem v gitu tak musí zálohovat tuhle /etc/.git, támhle /var/named/.git atd.Toto by sa dalo vyriešiť tak, že by sa kontroloval root adresár a do .gitignore by sa dalo pravidlo, aby sa všetky podadresáre ignorovali a povolili by sa tam len tie potrebné. PS: Samotný adresár .git sa môže umiestniť kamkoľvek (nemusí byť v tom root adresári).
můžu se zeptat co je to vcs? z gl vypadlo tohle, ale nedává mi to smysl..wikipedia:VCS
jdou nástroje jako etckeeper nastavit pro zálohování adresářů i mimo /etc? například ~/bin /var/lib ap.Predpokladám, že asi nie (aspoň nie jednoduchým spôsobom). Navyše, podľa mňa, v /bin, /usr/var/lib nie sú súbory, pri ktorých by malo zmysel archivovať si zmeny.
Predpokladám, že asi nie (aspoň nie jednoduchým spôsobom). Navyše, podľa mňa, v /bin, /usr/var/lib nie sú súbory, pri ktorých by malo zmysel archivovať si zmeny.
nemluvil jsem o /bin ale o ~/bin což jsou moje skripty
ve /var/lib jsou například dhcp leases(sleduju kdo je na síti, než udělám něco lepšího), nebo tor fingerprint a keys, které bych chtěl mít zálohovány stejným způsobem jako zbytek věcí ve stroji
Ono to jde použít i místo záloh – např. když máš webový server, více méně čistý Linux, verzuješ /etc, /var/www a textový dump z databáze. Samozřejmě verzuješ na nějaký jiný stroj (nebo přinejmenším disk). Když se celý server zhroutí, stačí znovu nainstalovat Linux, nainstalovat pár balíčků (chce to mít jejich seznam, aby je člověk nemusel lovit z paměti nebo znovu vymýšlet) a obnovit z verzovacího systému nastavení, weby a databázi.
Potíž při tomhle přístupu je akorát při velkých objemech a často se měnících datech – u zálohy se snadno smaže stará verze a člověk si může udržovat jen aktuální verzi – zatímco verzovací systém uchovává celou historii (i ty verze, o které už nestojíš).
Používám mercurial (hg) – verzovací systém. Víš, co jsi kdy měnil, můžeš si psát poznámky, vracet se zpátky. Taky poznáš, co se přesně změnilo během instalace aktualizace balíčků.
Akorát je potřeba dát pozor na práva k adresáři .hg (pro git platí totéž) – vlastníkem je root a nikdo jiný k těm souborům nemá přístup – jinak by si totiž obyčejný uživatel mohl „naklonovat“ toto mercurialové úložiště a dostat se k souborům, které jsou normálně chráněné přístupovými právy (např. soukromé šifrovací klíče, certifikáty).
Nevím. Jsem zvyklý na Mercurial 
Ale teď jsem si stahoval nějaké zdrojáky v gitu a jsou si hodně podobné.
Tiskni
Sdílej: