Ministerstvo financí ve spolupráci s finanční správou dnes představilo beta verzi aplikace využívající umělou inteligenci pro předvyplnění daňového přiznání. Není třeba přepisovat údaje z různých potvrzení, ani hledat správné řádky, kam údaje napsat. Stačí nahrát dokumenty a využít AI.
Výrobce počítačových periferií Keychron zveřejnil repozitář se schématy šasi klávesnic a myší. Licence je restriktivní, zakazuje většinu komerčních užití a v podstatě jsou tak data vhodná pouze pro výukové účely, hlášení a opravy chyb, případně výrobu vlastního příslušenství.
Správce balíčků APT, používaný v Debianu a odvozených distribucích, byl vydán ve verzi 3.2 (seznam změn). Mezi novinkami figurují nové příkazy pro práci s historií, včetně vracení transakcí.
Společnost Anthropic oznámila Projekt Glasswing a s ní související AI model Claude Mythos Preview. Jedná se o iniciativu zaměřenou na kybernetickou bezpečnost, do které se zapojily velké technologické společnosti Amazon Web Services, Anthropic, Apple, Broadcom, Cisco, CrowdStrike, Google, JPMorganChase, Linux Foundation, Microsoft, NVIDIA a Palo Alto Networks. Anthropic věří, že nový AI model Claude Mythos Preview dokáže
… více »Firma Ojective Development vydala svůj nástroj pro monitorování a řízení odchozích síťových připojení Little Snitch i pro operační systém Linux. Linuxová verze se skládá ze tří komponent: eBPF program pro zachytávání provozu a webové rozhraní jsou uvolněny pod GNU GPLv2 a dostupné na GitHubu (převážně Rust a JavaScript), jádro backendu je proprietární pod vlastní licencí, nicméně zdarma k použití a redistribuci (cena přitom normálně … více »
Vojenské zpravodajství (VZ) se v březnu zapojilo do mezinárodní operace proti aktivitám hackerské skupiny APT28, která je spojovaná s ruskou vojenskou zpravodajskou službou GRU a která přes slabě zabezpečené routery prováděla kybernetické útoky na státní a další organizace v ČR i zahraničí. Operaci vedl americký Federální úřad pro vyšetřování (FBI) a jejím cílem bylo odebrat útočníkům přístup k napadeným zařízením a ty následně … více »
Tvůrcem nejpopulárnější kryptoměny bitcoin, který se skrývá za pseudonymem Satoši Nakamoto (Satoshi Nakamoto), je britský kryptograf Adam Back. Na základě vlastní investigativní práce to tvrdí americký deník The New York Times (NYT). Několik indicií podle autorů jasně ukazuje na to, že Back a Nakamoto jsou stejný člověk. Jde mimo jiné o podobný odborný a osobnostní profil či totožné chyby a manýry v psaném projevu.
Google Chrome 147 byl prohlášen za stabilní. Nejnovější stabilní verze 147.0.7727.55 přináší řadu novinek z hlediska uživatelů i vývojářů. Podrobný přehled v poznámkách k vydání. Vylepšeny byly také nástroje pro vývojáře. Přehled novinek v Chrome DevTools 145 až 147 také na YouTube.
Vývojáři z Laboratoří CZ.NIC vydali nové verze aplikací Datovka (Datovka 4.29.0, Mobilní Datovka 2.6.2). V případě desktopové verze přibyly možnosti projít všechny uložené zprávy, zkontrolovat časy expirací časových razítek a přerazítkovat datové zprávy, které lze v ISDS přerazítkovat. Novinkou je také možnost vytahovat myší ze seznamu ZFO soubory datových zpráv, tento úkon jde udělat i pomocí tlačítek Ctrl+C. Nová verze Mobilní Datovky přináší jen drobné úpravy.
MicroPython (Wikipedie), tj. implementace Pythonu 3 optimalizovaná pro jednočipové počítače, byl vydán ve verzi 1.28.0. Z novinek lze vypíchnout novou třídu machine.CAN.
Byl jsem tázán, proč nemám důvěru k RAID řadičům, jaké se strkají do běžných počítačů. Váže se k nim následující historka. Před pár lety jsem si vymyslel, že si jako koupíme diskové pole, které bude tak spolehlivé, že nebude nutné ho zálohovat. Ono zálohování stovek GB a víc bývá pracné. Ještě i dnes si myslím, že to byla správná myšlenka. Můžeme přece mít dvě stejná pole jedno pracovní, druhé záložní obsahující mirror, a jednu paní, která v případě poruchy toho pracovního ho vypne, připojí to záložní a zase to spustí. To je velmi stabilní mechanismus. Při tom stačí paní nahradit robotem a máme co jsme chtěli, vlastně takový SAN. Jenže peníze na skutečný SAN nebyly.
Jedna seriózní firma od toho dala ruce pryč, druhá dobrodružnější to ale docela hezky vymyslela. Linuxový server, v něm ADAPTEC 2100S nakonfigurovaný tak, aby mirroroval, a k tomu dvě stejná políčka EasyStor SB-2803T s vnějším vývodem SCSI, obě připojená do SCSI chainu k tomu Adaptecu. Více než dva roky to běželo bez nejmenšího problému.
Na každém tom poli byly vytvořeny tři oddíly jakoby virtuální disky. Ten typ pole to umožňuje tak, že každý virtuální disk má stejné SCSI id ale různý LUN. Každý ten virtuální disk byl v mirroru se stejným na druhém poli. Jak říkám, dlouho to běželo pěkně a ti tři odvážlivci, kteří nám to navrhli a jaksi garantovali, mezitím vzali kramle.
Potom se mirror rozpadnul, běželo to na polovině a tedy bez zálohy a Adaptec ošklivě pištěl (nedivím se mu). To odpojené pole podle všech testů dál fungovalo, dalo se i připojit jinam a data tam byla. V logu polí nic, v logu linuxu taky nic. V logu Adaptecu velmi stručná hláška, že ten a ten disk chybuje a byl odpojen. Pokus o rebuild mirror obvykle během pár minut zhavaroval. Někdy taky doběhl, ale potom v provozu se to znovu rozpojilo. Přivolaný technik od té dodavatelské firmy se nás zdvořile zeptal, kdo nám takovou pitomou architekturu navrhnul. Nevěděl, co je na tom špatně, ale pořád říkal, že to přece nemůže fungovat.
Nazdařbůh jsme vyměnili ten Adaptec, ale ne za stejný, ten nebyl k mání. Za nějaký novější. Mělo by to být jedno. Raid řadič si píše služební údaje přímo na připojené disky, a to nejpíš na úplný začátek, kam souborové systémy nikdy nelezou. (Někdo jiný tam může lézt, např. Informix.) Dáte tam nový raid řadič, zapnete a má to hned zase běžet... skutečně bez nehod to naběhlo pro LUN=0 a hned se spustil rebuild správným směrem z dobrého na špatný. Ale pro vyšší LUNy to psalo, že mu chybějí obě poloviny mirroru, zato ale viděl pár nových disků, které tam ve skutečnosti nebyly. Po ručním zrušení mirrorů a jejich znovu vytvoření se to podařilo správně rozjet včetně toho správného směru buildu z dobrého na špatný. Jenže po pár dnech provozu se to znovu odpojilo, jak správně tušíte. Mezitím nám snaživý servisák na našem starém Adaptecu upgradoval firmware a při další výměně nazpátek se to už ani nenabootovalo. Vrátili jsme tam zase ten dočasný Adaptec a na něm to běží už skoro rok bez mirrorování. Mirror si děláme sami pomocí rsync.
Pominu určité emoční prožitky, které s naznačenými operacemi byly spojeny. Můžu pominout i to, že při jedné z manipulací nám data z jednoho oddílu zmizela, asi se spustil rebuild nesprávným směrem. Data jsme obnovili ze zálohy, protože v té době jsme na absolutní spolehlivost už tolik nevěřili. Ale stejně, co se vlastně stalo?
Něco očividně hnije v jednom z těch polí nebo v serveru. Ještě to nevyhnilo a tedy se to nedá poznat. Trapné selhání Adaptecu je vázáno na vyšší LUNy a to mu třeba můžeme odpustit. Možná má Adaptec milion instalací podobných destiček, ale nejspíš jednu jedinou s LUN != 0, takže to není odladěné.
No a ti tři mládenci, co nám to navrhli, škoda že vymizeli. Jeden z nich byl opravdu šikovný, možná by nám to spravil. Pořád nevím, že by na té jejich konstrukci bylo něco špatně. Až na to že nefunguje.
Tiskni
Sdílej:
V logu Adaptecu velmi stručná hláška, že ten a ten disk chybuje a byl odpojen.
Hm, mozna ze mam divny myslenkovy pochody, ale IMHO bych nejdriv vymenil ten a ten disk
Obávám se, že neexistuje způsob, jak se vyhnout plnohodnotnému zálohování. I když bych vzal dvě velmi kvalitní disková pole, připojil je každé k jinému počítači a zajistil jejich mirrorování, dostávám pouze systém, který mě s vysokou mírou spolehlivosti chrání před jakoukoliv myslitelnou hardwarovou závadou nebo jejich různými kombinacemi. (Nechrání samozřejmě úplně dokonale, protože se může stát, že odejde najednou 2xN disků ve dvou polích, ale to je natolik nepravděpodobné, že to můžeme vyloučit.)
V této fázi je značně eliminováno riziko hardwarového selhání a na povrch vystupuje nezanedbatelné riziko chyby lidského faktoru / softwarového selhání.
Pokud "master" té dvojice polí usoudí, že mají být obě smazána, jste prostě v háji. Přičemž k tomu může dojít z naprosto prozaické příčiny, například příkazem delete from xxx, kde člověk zapomněl dopsat where yyy - to se mi skutečně podařilo
.
Pokud máte celé zálohovací řešení online, k takovéto situaci dříve či později dojde. Proto by tam měl být vždycky nějaký offline prvek, který vaši chybu ihned slepě nezreplikuje, a vy budete mít šanci odněkud data získat zpět...
V této fázi je značně eliminováno riziko hardwarového selhání a na povrch vystupuje nezanedbatelné riziko chyby lidského faktoru / softwarového selhání.
Pokud máte celé zálohovací řešení online, k takovéto situaci dříve či později dojde. Proto by tam měl být vždycky nějaký offline prvek, který vaši chybu ihned slepě nezreplikuje, a vy budete mít šanci odněkud data získat zpět...
Samozřejmě. Tím není řečeno, že to nemůže být chytřejší robot. V našem řešení to dořešeno nebylo, to uznávám.