Google Chrome 156 byl prohlášen za stabilní. Přehled novinek v poznámkách k vydání. Opraveno bylo 353 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Indická společnost eMudhra po bezpečnostním incidentu, tj. kompromitaci soukromých klíčů osmi mezilehlých certifikátů své certifikační autority, opouští globální byznys s SSL/TLS certifikáty.
Dle Phoronixu zveřejnila společnost Trend Micro prostřednictvím programu Zero Day Initiative (ZDI) několik hlášení bezpečnostních zranitelností přímo na veřejném mailing listu LKML, přestože některé chyby dosud nemají opravu začleněnou do hlavní větve jádra. Mezi hlášenými problémy jsou dvě zranitelnosti s hodnocením CVSS 9.0, týkající se SMB Direct a KSMBD, které mohou umožnit vzdálené spuštění kódu. Další hlášení se týkají … více »
Správce hesel KeePassXC byl vydán ve verzi 2.8.0. Přechází na Qt 6, podporuje vkládání hesel s Waylandem, rychlé odemykání pomocí Polkitu nebo možnost nastavení klávesových zkratek (seznam změn).
Databáze DuckDB (Wikipedie) byla vydána ve verzi 2.0.0 LTS. S kódovým názvem Cinnamon Teal (čírka skořicová). S vyladěným protokolem Quack.
V implementaci Broadcom 802.11 byla zjištěna chyba ve zpracování WPS/EAP, týká se to SDK od roku 2010. Broadcom podle výzkumníka Quentina Kaisera odmítl CVE přidělit. Modemy Huawei a Technicolor jsou používány i v ČR, v LTE routerech, běžných domácích routerech a firemních přístupových bodech, jejich současný počet a zranitelnost konkrétních verzí však zatím neznáme. Více detailů a demo. GitHub / Broadcom 802.11 SDK Detection Toolkit.
Byla vydána nová verze 10.8 z Debianu vycházející linuxové distribuce DietPi pro (nejenom) jednodeskové počítače. Přehled novinek v poznámkách k vydání. Přibyl balíček DietPi WireGuard.
Oslavte vydání openSUSE Leap 16.1 s námi v Praze! Ve středu 4. listopadu 2026 (den po vydání Leapu 16.1) vás zveme na malou oslavu vydání openSUSE Leap 16.1 do pražské kanceláře SUSE. Připravili jsme pro vás dvě krátké přednášky: … více »
Dle plánu bylo PHP vydáno v nových verzích 8.5.12, 8.4.27, 8.3.36 a 8.2.35. Opraveny jsou kritické zranitelnosti CVE-2026-109618 a CVE-2026-109619 aneb PHP2Shell.
UBports, nadace a komunita kolem Ubuntu pro telefony a tablety Ubuntu Touch, vydala Ubuntu Touch 24.04-2.1 a 24.04-1.5. S opravou kritických zranitelností.
Asi tak, ty zase tak laciný nejsou ...
spíš by mě zajímalo, jestli o X letech budech v čem přečíst.
v CT 16 vysel clanek o zalohovani na DVD, 24 karat nepouziva ani ten Verbatim za tech 25 kc/kus nybrz stribrnou a zlatou vrstvu. To je momentalne pry to nejlepsi. Podle mereni staci u Verbatimu prezalohovat za 18 let, podobne DVD od Kodaku statisticky kazdych 8 mesicu ( z toho je videt, jak jsou mnohdy marketingova tvrzeni licha) Zalezi tedy hrozne na nosici , doporucuje se skutecne ten long-time Verbatim.
Na vypalovacce pry kupodivu tolik nezalezi.
Problem vidim ve vypalovacim programu, ktery by fungoval jako batch. Za poslednich 5 let jeste nefungoval dobre na DVD jeste zadny. Grovisofs drive nekdy zablokoval DVD v supliku(suse 9.1 2.6.4) a musel se restartovat server, na slack 10.0 (2.4.18) zase 1 x ze tri pokusu proste rekne, ze zalohovat nebude, ze child process zmizel. Doufam, ze ted s Centos 5.0 to bude konecne fungovat.
Co je prosím CT 16? Rád bych si to přečetl. Děkuji.
omlouvam se, spravne c't magazin , .. nejprodavanejsi IT magazin v Evrope, vytah toho clanku z cisla 16 viz:
http://www.heise.de/ct/08/16/116/
Já zálohuji především na externí disk a to tak, že nejdůležitější data ukládám prostřednictvím cronu do adresářů pro pondělí až pátek (pět různých verzí), dále tabulky z databáze na jiný počítač každé dvě hodiny. Jednou týdně pak na DVD, které odnáším na jinou adresu. Takže doufám, že důležitá data jsou relativně v bezpečí, pokud jde o jejich ztrátu.
DVD Verbatim (po 6 korunách za kus?), a měnící se data jednoduše přenášíme na oddělený počítač.
Od toho mame filesystemy jako JFS, ktere nemaji s vypadky problemy.
rm na víc souborů, než jsi chtěl, "návštěva" v systému, překlep při používaní dd atd.? Prostě i kdybych měl dva disky, tak bych ten druhý připojoval jenom jednou denně na zálohu.
soubory sice mohou byt omylem smazany ale jenom za predpokladu ze uzivatel udela chybu. A to se me netyka...
)))
Jenže soubory mohou být poškozeny i jinak. Nějakou aplikací, chybou filesystému, možností je spousta.
A to se me netyka...)))
Gratuluju.
soubory sice mohou byt omylem smazany ale jenom za predpokladu ze uzivatel udela chybu.
Ale kdepak. I kdybys byl naprosto neomylný, tak stačí, když v dobré víře spustíš skript nebo aplikaci, jejíž autor udělal chybu nebo něco nedomyslel.
Teď mě napadá: jestli nikdy nechybuješ, tak jak to, že ještě nepracuješ u nás jako kernelový vývojář? Takové bychom potřebovali 
jestli nikdy nechybuješ, tak jak to, že ještě nepracuješ u nás jako kernelový vývojář?Takoví už tady byli, a jak dopadli! Teda až na to, že Hans nepracoval v SUSE
Jednomu známému zdroj odpálil oba disky v RAID1 
Dělám si srandu, docela bych koukal, kdybych teď přišel o disk...
mam par desitek GB nejdulezitejsich dat vypalenych na DVD, ulozene na tmavem a suchem miste(v supliku
), jinak nezalohuju, predpokladam ze mp3, filmy a podobne nesmysly neni potreba zalohovat.
Interní HDD připojený oddíl + Externí HDD trvale odpojený, důležité věci mám i na optických médiích.
V současnosti zalohuju na svuj "server v komoře", a to denně. Už před lety jsem si na to napsal home-made skript založený na rsyncu. Funguje to skvěle jak pro můj notebook, tak pro produkční server.
Už delší dobu ale uvažuju, že by bylo skvělé využít něco jako distribuovanou síť záloh, P2P backup network. Před časem jsem hledal a vygooglil jsem nástroj Flud backup, zatím jsem ale žádné reálné testy nedělal a ani nezkoumal detaily architektury. Co jsem pochopil, každý zálohovaný node posílá svá data do sítě a zároveň lokálně ukládá cizí data, takže v případě výpadku node (nebo v případě nutnosti obnovit nějaký konkrétní soubor) je možné zrekonstruovat zálohovaná data ze sítě.
Záleží hodně na implementaci, nejen kvůli propustnosti sítě, ale také kvůli zabezpečení a možnosti správy záloh - přece jen bych se necítil, kdybych měl svou jedinou zálohu realizovat přes nějaký blackbox.
Distribuované zálohy jde z principu realizovat buď lokálně - v rámci svých pár počítačů nebo opravdu decentralizovaně přes Internet. Ta druhá varianta mi přijde zajímavější, především pro lidi, kteří nemají dostatek vlastních nodů pro vytvoření své privátní sítě. Kdybyste někdo chtěl zalaborovat (například) s Fludem, napište mi na jabber...
Svoje data odmietam "preposielat" ci dokonca ukladat skrz internet a to ani v kryptovanej podobe. Su to moje sukromné fotky, dokumenty, moja práca, námaha a pod. A nerád by som ak by sa k tomu niekto neopravneny dostal...
Kdybys byl banka, případně nějaká velká firma, tak to beru. Ale upřímně - tvoje data nikoho nezajímají
natolik, aby složitě decryptoval data, která si na svém počítači asynchronně zašifruješ.
Nejsem takový paranoik, abych k serveru chodil fyzicky namísto přihlašování k SSH. A tohle vidím jako naprosto stejnou věc.
A dokumenty, zdrojáky, apod. nějak moc místa zas nezaberou...
povazuje sa torrent za zalohu? :-)
Pokud mas vsechny osobni fotky, pracovni projekty, pristupove udaje na vsechny bankovni ucty apod na torrentech a dostatek lidi ti je seeduje, tak proc ne
.
Nejtrvanlivejsi medium pro zalohovani je kamen. Jeho nevyhodou vsak je nizka kapacita.
A jedna vseobecne znama veta k otmu:
Existuji pouze 2 druhy dat. Ty zalohovane a ty ztracene.
Pokud vám nevadí, že rychlost zápisu není z nejvyšších, tak bych to jako problém neviděl. Šutrů je totiž dost. 
Určitě. Admini okolo Tutanchámona o tom věděli své. 
Přes rsync na flashku a z ní na druhý počítač a obráceně. Kvůli omylem smazaným souborům tu mám rdiffbackup přes cron-hourly bohužel zatím na ten samý disk, takže nic moc, ale párkrát už jsem si něco obnovil.
hele pamatuješ, jak jsem tuhle vypaloval ten seriál, máš to ještě, že jo, ..."jj minuly tyden jsem ti rozsifroval tu divnou prilohu..."
Používám TimeMachine, maximální spokojenost a jednoduchost ovládání.
Mělo by se kvalitativně rozlišovat (i v diskusi):
A) zálohovat (pro případ rozpadu databáze, vadného HW za účelem obnovy systému)
B) archivovat (za účelem uchování historie)
add A) hl.parametr - rychlost zápisu a obnovy, přenositelnost
add B) hl.parametr - životnost nosiče (podle statistik vedou mg.páskové nosiče)
Na desktopu na prubezne zalohy DVD-RAM (zaradit to do grafu k optickym mediim typu DVD-R za 8 Kc se mi moc nechce), na trvalou archivaci CD-R se zlatem, ale zas tak moc tomu neverim.
Arichivace CD-R se zlatem je dobrá volba - ale zase jen do doby, než příjde nezvaná návštěva, oheň nebo povodeň ...
Já mám v PC dva pevný disky. Na druhý provádím zálohy.
na sitovy externi disk, stale pripojeny...nejdulezitejsi data jeste na dvd
Tiskni
Sdílej: