Edvard Rejthar na blogu zaměstnanců CZ.NIC představil svou aplikaci SlideRshow (GitHub). Funguje jako prohlížeč fotek, ale i jako jejich organizér a prezentátor. Neinstaluje se, běží přímo v prohlížeči. Bez serveru. Offline.
Kermit, tj. protokol pro přenos souborů, vznikl před 45 lety. Při této příležitosti byla po 15 letech od vydání poslední stabilní verze 9.0.302 vydána nová stabilní verze 11 implementace C-Kermit. S podporou IPv6.
První verze konverzního nástroje Pandoc byla vydána před 20 lety. Jeho autor John MacFarlane při tomto výročí rekapituluje jednotlivé etapy vývoje a přidávání nových funkcí – rozšíření nejen Markdownu a podporu mnoha dalších formátů.
Srpen přinesl nejen další spalující vedro, ale také Virtuální Bastlírnu s neméně žhavými novinkami. Využijte tedy předpovědi na deštivý čtvrteční večer a od 20:00 se připojte online k tomuto neformálnímu setkání kutilů, techniků a vědců, kde se strahovskými bastlíři proberete nejzajímavější věci, na které jste narazili za poslední měsíc. Pokud jde o novinky, řeč zcela jistě přijde na systém INDX pro tiskárny Průša, který na konci
… více »Firma T-Mobile blokovala „dezinformační web“ AC24 bez toho, aniž by k tomu měla závazný pokyn orgánů veřejné moci. Píše to ve svém rozsudku Městský soud v Praze, který po čtyřech letech uzavřel kauzu blokace zmíněného webu. Operátor musí uhradit škodu ve výši 35 tisíc korun. Advokát společnosti T-Mobile se snažil i u odvolacího senátu argumentovat tím, že firma jednala v dobré víře, když na stránky omezila přístup poté, co ji k tomu vyzvalo
… více »Padla obžaloba v bitcoinové kauze. Státní zástupkyně chce pro Blažka 6,5 roku vězení, pro Titze 8 let.
Z aktuálních globálních statistik společnosti Statcounter: na desktopu má Linux celosvětově podíl 7,53 % (USA 11,92 %, Česko 4,31 %, Slovensko 4,36 %) a Firefox celosvětově podíl 6,51 % (USA 10,86 %, Česko 11,07 %, Slovensko 13,61 %).
Na GitHubu byl publikován seznam 55 kritických bezpečnostních chyb v SQLite s přiřazenými CVE čísly. JFrog Security informuje, že se jedná jenom o AI slop, části kódu na které CVE odkazují, v daných verzích vůbec neexistují. Upozorňuje také, že čísla CVE jsou přiřazována bez ověřování.
Příspěvek na blogu Google Security popisuje, jak tým Chrome Security využívá umělou inteligenci k zásadnímu zrychlení a zlepšení procesu odhalování, třídění a opravování bezpečnostních chyb v prohlížeči Chrome. Díky AI byla nalezena kritická chyba, která byla v kódu přes 13 let. Ve verzích Chrome 149 a 150 bylo opraveno více chyb než v předchozích 23 verzích dohromady.
Firmy v EU musí počínaje dnešním dnem označovat obsah vytvořený umělou inteligencí. Znamená to povinnost informovat uživatele, že člověk komunikuje s chatbotem či jiným systémem AI. Rovněž obrázky, audia či videa, které jsou vytvořené nebo zmanipulované pomocí umělé inteligence a které mohou působit jako autentické, musejí být jasně označeny jako uměle vytvořené.
Já používám všude discard (skrz Btrfs, LUKS i LVM), ale zdá se, že to může být víc škody než užitku. Těžko říct. Asi to teda mám všechno špatně.
autodefrag mám všude zapnutý, i na SSD, ve stylu „because we can“. Je na nekonečnou debatu, jestli to dává smysl. Výkon by to zlepšovalo jedině při nějaké extrémní fragmentaci, která je nepravděpodobná. Opotřebení SSD to asi zvyšuje, ale jedině pokud je nějaká defragmentace skutečně potřebná a provádí se. Beru to tedy tak, že v případě hypotetické extrémní fragmentace by to (trochu) pomohlo s výkonem, za cenu opotřebení SSD — ale SSD je prostě k tomu, aby se používalo, takže co má být —, a v jakémkoliv jiném (běžném) případě to nedělá skoro nic.
Ano, chattr +C je pořád asi jediná možnost, jak lokálně aplikovat nodatacow. Disky s virtuály bych rozhodně dal do odděleného subvolume, aby se dalo v budoucnu plynule přejít na ten mount option, až jednou (snad) bude per-subvolume.
Mám za to, že fstrim používá seznam volných bloků v souborovém systému a ten bude fungovat vždy, zcela bez ohledu na to, zda je příslušné zařízení šifrované či nikoliv.
Problém je ale v tom, že discard i fstrim můžou (teoreticky) u šifrovaného zařízení vést k úniku jistých dat (například o rozmístění různých bloků se známým obsahem) a tím k oslabení zabezpečení, které šifrování poskytuje. Pár odkazů je tady. Záleží také na zvoleném typu šifry.
Já ho tam vždycky dávám. I kdybych nakonec při mountu filesystému discard nepovolil, není od věci mít discard uschopněný na všech ostatních vrstvách jako LUKS, LVM, GPT, kdovícoještě až po hardware. Pak se celá věc ovládá na jednom místě (mount option nebo spuštění fstrim) a není třeba myslet na těch několik dalších vrstev (a hledat v dmesg, kde se to zadrhlo).
…tak bych vlastně discard pro LUKS v /etc/crypttab nemusel (neměl) řešit?
Měl, protože /etc/crypttab se (pokud se nepletu) zkopíruje z /etc do toho initcpio obrazu / souborového systému, aby se v initramdiskové fázi bootu dal ten šifrovaný kontejner otevřít rovnou správným způsobem. A právě tam už musí to nastavení být, má-li se uplatnit.
Pokud jde o souborový systém uvnitř toho LUKS kontejneru, já dávám povolení discardu i do kernelových optionů, ale v tomhle jdu špatným příkladem ;-P, protože je to zbytečná blbost — v implicitním nastavení se totiž root (/) namountuje napřed read-only, takže discard nedává žádnž smysl, a pak se později přemountuje read/write, už podle /etc/fstab, kde bude discard povolený. Protože se provádí remount na read/write, discard se prostě bez problémů zapne.
U toho LUKS kontejneru/oddílu se ovšem žádná obdoba remountu nedělá — jakmile je na něm root (/), bude už otevřený stejným způsobem po celou dobu uptime systému. Proto by měl mít nastavení už od úplného začátku.
Ve Fedoře existují kernelové optiony, které si přečte Dracut a které umožňují zapnout discard v LVM, LUKS i Btrfs nezávisle na další konfiguraci systému. Už si nevzpomínám, jak přesně je to v Archu a/nebo na vanilla kernelech. Ale /etc/crypttab rozhodně v Archu funguje ve spojení s mkinitcpio přesně podle očekávání, tj. zkopíruje se do toho úvodního ramdisku (dokonce s hláškou během vytváření toho initcpio obrazu) a použije se pak při bootu velmi brzy, přesně jak je potřeba.
/etc/mkinitcpio.conf v sobě správné hooky. Já mám například na jednom systému nešifrovaný /boot, protože GRUB kdysi dávno neuměl LUKS a neuměl tedy bootovat z šifrovaného oddílu (ach jo), takže mám GPT tabulku oddílů, na ní je EFI boot oddíl a druhý oddíl s LVM, v tom LVM je /boot (nešifrovaný) a všechno ostatní je LUKS oddíl, v LUKSu je další vrstva LVM a v něm malý swap a Btrfs (vše ostatní). Je to stejné jako konfigurace popsaná tady. Hooky v Archu pak musí být něco jako … lvm2 encrypt lvm2 resume …, aby se všechny vrstvy otevřely. (To například na Fedoře není potřeba, protože tam Dracut sám rekurzivně hledá a otevírá vrstvy abstrakce tak dlouho, dokud nenajde oddíl s požadovaným UUID, který poslouží jako root.)
Dnes už bych tohle^^^ asi nedoporučoval, protože GRUB umí LUKS, takže je možné mít jen jednu vrstvu LVM. Tedy mít GPT, na tom EFI + LUKS oddíly a v LUKS oddíle buď rovnou Btrfs, nebo LVM a na tom jeden swap LV a jeden Btrfs LV.
[petr@Archbang Diablo II]$ cat /etc/fstab UUID=1e1286cc-4640-46fc-8fd4-918b61f129cd / btrfs rw,relatime,ssd,space_cache,subvolid=5,subvol=/ 0 0 # /dev/sda6 UUID=b53aef57-cee8-472e-a8c9-d20b482c7198 /home btrfs rw,relatime,ssd,space_cache,subvolid=5,subvol=/ 0 0 [petr@Archbang Diablo II]$Nějak jsem se v tom nehrabal a swap už tak 3 roky vyplý (core i5 2450m @2.5GHz, 6GB RAM) a problém jsem nenašel. SSD je OCZ Vertex 4 a už to bude hezkých pár let, co jej mám :). Právě jedu na plasmě 5.7.x a ani GnomeShell nebo cokoliv jiného si nestěžovalo. Cheers
Tiskni
Sdílej: