Během akce Arduino Days 2026 byl publikován Arduino Open Source Report 2025 (pdf) a oznámeno 7 nových produktů kompatibilních s deskou UNO Q (Arduino USB-C Power Supply, USB-C Cable, USB-C Hub, UNO Media Carrier, UNO Breakout Carrier, Bug Hopper, Modulino LED Matrix).
Google v pátek spustil v Česku Vyhledávání Live. Tato novinka umožňuje lidem vést plynulou konverzaci s vyhledávačem v češtině. A to prostřednictvím hlasu, nebo prostřednictvím toho, na co ukážou svým fotoaparátem či kamerou v mobilu. Rozšíření této multimodální funkce je možné díky nasazení Gemini 3.1 Flash Live, nového hlasového a audio modelu, který je od základu vícejazyčný, takže umožňuje lidem po celém světě mluvit na vyhledávač přirozeně a v jazyce, který je jim nejbližší.
Jsongrep je open-source nástroj, který efektivně prohledává JSON dokumenty (editovat je neumí). Kompiluje regulérní jazyk dotazu do podoby deterministického konečného automatu (DFA), díky čemuž prochází strom JSON dokumentu pouze jednou a je v tom tedy rychlejší než jiné nástroje jako jsou například jq, JMESPath nebo jql. Jsongrep je napsaný v programovacím jazyce Rust, zdrojový kód je dostupný na GitHubu.
O víkendu probíhá v Praze na Karlově náměstí 13 konference Installfest 2026. Na programu je celá řada zajímavých přednášek a workshopů. Vstup na konferenci je zcela zdarma, bez nutnosti registrace. Přednášky lze sledovat i online na YouTube.
Mozilla a společnost Mila oznámily strategické partnerství za účelem rozvoje open source a suverénní AI. Cílem je ukázat, že open source AI může konkurovat uzavřeným systémům. Obě organizace chtějí posílit technologickou suverenitu a snížit závislost na hrstce velkých technologických firem.
Adam Rice předvedl, že pomocí DNS lze distribuovat a spustit kompletní hru DOOM. Rozdělil WAD soubory a binárky do téměř 2000 DNS záznamů v Cloudflare zóně (jeden TXT záznam v DNS může nést okolo 2000 znaků textu). Ty pak stáhl PowerShellem, dekomprimoval a spustil přímo v paměti počítače bez nutnosti zápisu na disk, což prakticky dokazuje, že DNS může sloužit jako distribuované úložiště dat a možný kanál pro načítání kódu. Repozitář projektu je na GitHubu.
Dnes a zítra probíhají Arduino Days 2026. Na programu je řada zajímavých přednášek. Sledovat je lze od 17:00 na YouTube. Zúčastnit se lze i lokálních akcí. Dnes v Poličce v městské knihovně a zítra v Praze na Matfyzu.
Byla vydána beta verze Ubuntu 26.04 LTS s kódovým názvem Resolute Raccoon. Přehled novinek v poznámkách k vydání. Dle plánu by Ubuntu 26.04 LTS mělo vyjít 23. dubna 2026.
Byla vydána aktualizována Příručka pro začínající wikipedisty a wikipedistky (pdf).
Ubuntu plánuje v budoucích verzích nahradit tradiční nástroje pro synchronizaci času (chrony, linuxptp a gpsd) novým, v Rustu napsaným ntpd-rs, který nabídne vyšší bezpečnost a stabilitu.
Chtěl jsem si zazálohovat svoji sbírku hudby (asi 50 GiB), které schraňuji na externím USB disku, na svůj starý desktop (který nyní spokojeně používá moje maminka; na GMail a trochu bulváru je Ubuntu jak dělané).
Abych to mohl pohodlně provést, potřeboval jsem udělat trochu harakiri s diskovými oddíly. Nakonec jsem skončil na tom, že jsem chtěl spojit dva oddíly ležící vedle sebe, jeden z nich byl primární, druhý druhý logický. To bohužel v nástroji gparted nelze nakliknout (inu, není to PartitionMagic), tak jsem se rozhodl udělat to přes LVM (aspoň se s tím konečně naučím).
Po instalaci LVM se vytvořil nový initramdisk, tak jsem si říkal, že cvičně rebootnu. Jaké bylo mé překvapení, když GRUB ani nezobrazil menu a skončil na mysteriózní chybě číslo 17. Vyhrabal jsem někde ubuntí lajvko a jal se zjišťovat, co se stalo. Data na disku se zdála v pořádku, oddíly na svých místech, všechno mountovatelné. Ovšem cfdisk se nespustil s tím, že tabulka oddílů nějaká špatná a že se oddíly překrývají.
Vím, že tabulka oddílů je díky historii adresování disku tak trochu magie, oddíly vytvořené v různých operačních systémech se nemusí snést. Takže proč nefunguje cfdisk jsem nezjistil (obyčejný fdisk též chybu nehlásil). Příčinu chyby kterou hlásil GRUB jsem taky nezjistil, naštěstí pomohla jeho prostá reinstalace.
Spojení oddílů s LVM byla hračka. Pak jsem začal s kopírováním. Bohužel připojení disku přes USB se ukázalo příliš pomalé, nevytáhl jsem z toho ani 1 MB/s vyhlídka na dvacetihodinové kopírování mě moc nenadchla. Tak jsem disk připojil ke svému notebooku a udělal to svým oblíbeným netcatem. Asi takhle (první řádek na cílovém počítači, druhý na zdrojovém):
netcat -l -p 7000 | tar x tar cf - * | netcat otherhost 7000
Přes wifi to nebylo o moc rychlejší, zapojil jsem tedy starý dobrý ethernetový kabel a pak to frčelo plnou rychlostí síťové infrastruktury, tedy asi 10 MiB/s.
Během kopírování jsem si všiml, že se mé mptrojky vejdou na vytvořený LVM oddíl jen tak tak, rozhodl jsem se jej tedy zvětšit (nechal jsem si na VG trochu rezervu). Oddíl jsem naformátoval jako ext3 právě proto, že umožňuje zvětšení za běhu, bez odmountování. Zvětšení oddílu a souborového systému proběhlo docela rychle a dokonce bez toho, aby se kopírování nějak zadrhlo. To se mi líbilo a užíval jsem si, jak tu technologii pěkně ovládám.
Spát jsem šel asi o půl třetí, ale mise splněna. Teď ještě zkouším upgrade toho Ubuntu na nejnovější verzi (abych zjistil, jestli to můžu příště nechat na mamince).
Tiskni
Sdílej:
Ja pouzivam ssh
priklad:
tar -c cesta | ssh uzivatel@stroj "tar -x"
alebo:
dd if=/dev/particia bs=1M | ssh uzivatel@stroj "dd of=/dev/particia"
Tiez to slape pekne rychlo (to ddcko pise 10-11 MB/s). Trochu to viac zatazuje pocitac, ale aspon nelezu moje data po sieti nesifrovane (co samozrejme doma na lokalke nevadi, ale v praci uz hej)
tar -c cesta | ssh uzivatel@stroj "tar -x"
+1, s tým, že to zvyknem na cestu ešte aj zagzipovať (ale keby som presúval mp3, obrázky či videá, tak to nemá zmysel)
Myslím, že gzip může být na starších strojích brzda... Spíš to chce třeba LZO...
scp -r cesta uzivatel@strojSCP to vsetko zenie jedinym TCP spojenim, takze to nema pri velkom mnozstve malych suborov ten strasny overhead ako FTP .
No, je to sice hezky reseni, mam dojem, ze neco takovyho jsem taky nekdy pouzival, nicmene, az to ti pri tomhle kopirovani nekde spadne a budes muset zacit znovu cely, pak si budes rikat, ze by to chtelo neco, co by to umelo podobne, ale samo poznat, co uz je zkopirovany a co ne. A pak si treba vzpomenes na rsync. Samozrejme nemyslim rsync pres ssh, ale ciste rsync na rsync daemon. Samozrejme, na jednej (server) strane to chce udelat konfigurak, ale ten muzes prakticky zkopirovat z man rsyncd.conf, staci neco takovyho
uid = root gid = root use chroot = no log file = /dev/stdout write only = no [mp3] path = /data/mp3 comment = MP3
Pak uz jenom na serveru spustis rsync --daemon --no-detach --config-file=./rsyncd.conf -v a na clientovi das treba rsync -avP ZDROJ-MP3/ rsync://server/mp3/ a kopirujes pres rsync nesifrovane. Ano, rsync protocol ma nejakou rezii, za tu ale dostanes komfort v znameni rozpoznani uz zkopirovanych souboru, castecne zkopirovanych a nezkopirovanych, moznost preruseni kopirovani atd.
Jinak ale urcite potvrdis pro ostatni odpurce LVM, ze vyhody LVM se ukazou, az kdyz zacnes potrebovat prave takovyhle zmatky, ze?:)
S netcatem jde uzit spousta srandy. Ja jsem takhle poustel kamaradovi novou muziku, co jsem sehnal:
nc -l -p 1234 < muzika/kapely/Heaven\ Shall\ Burn/Antigone/Heaven\ Shall\ Burn\ -\ Antigone\ 02\ the_weapon_they_fear.mp3On:
nc moje.ip.adre.sa 1234 | mplayer -
Dobře využitelný zápisek, máš bodík 
A i komentáře se dají využít 