Google oznámil, že Quick Share na Androidu funguje s AirDropem na iOS. Zatím na telefonech Pixel 10. Uživatelé tak mohou snadno přenášet soubory z telefonů s Androidem na iPhony a obráceně.
Byla vydána nová verze 8.5 (8.5.0) skriptovacího jazyka PHP používaného zejména k vývoji dynamických webových stránek. Přináší řadu novinek a vylepšení (URI Extension, Pipe Operator, Clone With, …). Vydána byla také příručka pro přechod z předchozích verzí.
Evropská komise zahájila tři vyšetřování týkající se cloudových platforem Amazon Web Services (AWS) a Microsoft Azure. Evropská exekutiva, která plní také funkci unijního antimonopolního orgánu, chce mimo jiné určit, zda jsou americké společnosti Microsoft a Amazon v cloudových službách takzvanými gatekeepery, tedy hráči, kteří významně ovlivňují provoz internetu a musí dle nařízení o digitálních trzích (DMA) na společném trhu
… více »Společnost Meta Platforms vyhrála ostře sledovaný spor o akvizici sítě pro sdílení fotografií Instagram a komunikační aplikace WhatsApp. Podle amerického soudu firma jejich převzetím neporušila antimonopolní zákon, protože si tak nemonopolizovala trh sociálních sítí. Žalobu na Metu podala před pěti lety americká Federální obchodní komise (FTC). FTC argumentovala, že Meta, tehdy známá jako Facebook, koupila tyto dvě společnosti v letech 2012 a 2014 proto, aby s nimi nemusela soutěžit.
Home Assistant včera představil svůj nejnovější oficiální hardware: Home Assistant Connect ZBT-2 pro připojení zařízení na sítích Zigbee nebo Thread.
Byla vydána verze 9.1 open source virtualizační platformy Proxmox VE (Proxmox Virtual Environment, Wikipedie) založené na Debianu. Přehled novinek v poznámkách k vydání a informačním videu.
Byl aktualizován seznam 500 nejvýkonnějších superpočítačů na světě TOP500. Nejvýkonnějším superpočítačem zůstává El Capitan od HPE (Cray) s výkonem 1,809 exaFLOPS. Druhý Frontier má výkon 1,353 exaFLOPS. Třetí Aurora má výkon 1,012 exaFLOPS. Nejvýkonnější superpočítač v Evropě JUPITER Booster s výkonem 1,000 exaFLOPS je na čtvrtém místě. Nejvýkonnější český superpočítač C24 klesl na 192. místo. Karolina, GPU partition klesla na 224. místo a Karolina, CPU partition na 450. místo. Další přehledy a statistiky na stránkách projektu.
Microsoft představil Azure Cobalt 200, tj. svůj vlastní SoC (System-on-Chip) postavený na ARM a optimalizovaný pro cloud.
Co způsobilo včerejší nejhorší výpadek Cloudflare od roku 2019? Nebyl to kybernetický útok. Vše začalo změnou oprávnění v jednom z databázových systémů a pokračovalo vygenerováním problém způsobujícího konfiguračního souboru a jeho distribucí na všechny počítače Cloudflare. Podrobně v příspěvku na blogu Cloudflare.
Byla vydána (Mastodon, 𝕏) první RC verze GIMPu 3.2. Přehled novinek v oznámení o vydání. Podrobně v souboru NEWS na GitLabu.
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 