Dnes a zítra probíhá vývojářská konference Google I/O 2025. Sledovat lze na YouTube a na síti 𝕏 (#GoogleIO).
V Bostonu probíhá konference Red Hat Summit 2025. Vybrané přednášky lze sledovat na YouTube. Dění lze sledovat na síti 𝕏 (#RHSummit).
Společnost Red Hat oficiálně oznámila vydání Red Hat Enterprise Linuxu 10. Vedle nových vlastností přináší také aktualizaci ovladačů a předběžné ukázky budoucích technologií. Podrobnosti v poznámkách k vydání.
Tuto sobotu 24. května se koná historicky první komunitní den projektu Home Assistant. Zváni jsou všichni příznivci, nadšenci a uživatelé tohoto projektu. Pro účast je potřebná registrace. Odkazy na akce v Praze a v Bratislavě.
Troy Hunt představil Have I Been Pwned 2.0, tj. nový vylepšený web služby, kde si uživatelé mohou zkontrolovat, zda se jejich hesla a osobní údaje neobjevili v únicích dat a případně se nechat na další úniky upozorňovat.
Microsoft představil open source textový editor Edit bežící v terminálu. Zdrojové kódy jsou k dispozici na GitHubu pod licencí MIT.
V Seattlu a také online probíhá konference Microsoft Build 2025. Microsoft představuje své novinky. Windows Subsystem for Linux je nově open source. Zdrojové kódy jsou k dispozici na GitHubu pod licencí MIT.
Z příspěvku Turris Sentinel – co přinesl rok 2024 na blogu CZ.NIC: "Za poslední rok (únor 2024 – únor 2025) jsme zachytili 8,3 miliardy incidentů a to z 232 zemí a z jejich závislých území. Tyto útoky přišly od 6,2 milionu útočníků (respektive unikátních adres). SMTP minipot je stále nejlákavější pastí, zhruba 79 % útoků bylo směřováno na tento minipot, 16 % útoků směřovalo na minipot Telnet, 3 % útoků směřovaly na minipot HTTP a 2 % na minipot FTP. Dále jsme zaznamenali 3,2 milionu unikátních hesel a 318 tisíc unikátních loginů, které útočníci zkoušeli."
Byla vydána (Mastodon, 𝕏) nová verze 3.0.4 svobodné aplikace pro úpravu a vytváření rastrové grafiky GIMP (GNU Image Manipulation Program). Přehled novinek v oznámení o vydání a v souboru NEWS na GitLabu. Nový GIMP je již k dispozici také na Flathubu.
Byla vydána nová stabilní verze 7.4 webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 136. Přehled novinek i s náhledy v příspěvku na blogu.
Diskuse byla administrátory uzamčena.
Instalátor dokáže nainstalovat systém i do šifrovaného BTRFS oddílu, ale je to komplikovanější. Je třeba vytvořit nešifrovaný malý oddíl /boot formátovaný jako EXT4 stejně jako v prvním případě, ale potom vytvořit to, co v instalátoru se jmenuje jako „fyzický svazek pro šifrování“ což je oddíl šifrovaný pomocí LUKS. Co instalátor v tuto chvíli po zadání šifrovacího hesla udělá je ale, že vnitřek tohoto šifrovaného oddílu rovnou naformátuje jako ext4, aniž by se zeptal. Lze ale v druhém kroku tento odemčený oddíl (pokud je ten šifrovaný sda2, tak instalátor ten odemčený připojí jako sda2_crypt) přeformátovat na jiný souborový systém, tj. i BTRFS, říct, že na něm má být přípojný bod / a instalátor si s tím poradí a nainstaluje se i na šifrovaný BTRFS.Cool. Tohle mě ve starších verzích trochu štvalo. Ne že by to asi nešlo, ale je to neintuitivní a pokud člověk neví, že to tak má udělat, tak na to jen tak nepřijde.
No ono to porad JE velmi neintuitivni, respektive kdyz jsi poweruser co vi presne co chce docilit a pochopi pojmy instalatoru a nespokoji se s ext4 a rozhodne se odemcene LUKS zarizeni rucne zvolit a znovu preformatovat, tak to nejak instalator zkousne. Ale to ze je treba mit ten /boot oddil bokem atd. se ten instalator samozrejme nezepta...
Dovedu si predstavit i jinou moznost jak provest tou instalaci a vyberem oddilu. Momentalne takove to "preinstalovat cely disk Ubuntu/Mintem" a nebo "Rucni vyber" jsou dva extremy. Ta jednodussi volba "nainstalovat" by jeste mohla obsahovat nejake "pokrocile nastaveni" ale ne zas az tak moc pokrocile, typu vyber "chci lety provereny system ext4 (a strucne info o vyhodach takoveho reseni i limitech), nebo "chci pokrocily btrfs" (a zase nejake vyhody treba ty rychle snapshoty, a nevyhody treba nejaka vyssi rizika ztraty dat,experimentalni filesystem a janevimco),a vedle toho zaskrtavatko "chci cely disk sifrovat" ano/ne. JIne filesystemy nez ext4 a btrfs jsou IMHO vhodne jen do te expertni instalace, sifrovani bych mozna v roce 2018 dokonce nabizel jako default a spis volit "opt out".
No ono to porad JE velmi neintuitivni, respektive kdyz jsi poweruser co vi presne co chce docilit a pochopi pojmy instalatoru a nespokoji se s ext4 a rozhodne se odemcene LUKS zarizeni rucne zvolit a znovu preformatovat, tak to nejak instalator zkousne. Ale to ze je treba mit ten /boot oddil bokem atd. se ten instalator samozrejme nezepta...Jo, já vím, kdysi jsem tu o tom psal blog, když to ještě neuměl vůbec: Mint 12 na šifrovaném disku (návod) + pár dojmů
Dovedu si predstavit i jinou moznost jak provest tou instalaci a vyberem oddilu.Já mám zrovna na disku právě ext4 a uvažuji, že si koupím větší SSD (to chci už delší dobu) a při té příležitosti bych tam právě hodil btrfs na LUKSu. V tomhle mě tedy ten tvůj blog docela navnadil.
Uf, tak to teda byly dřevní doby to takhle šíleně hackovat. Já začínal na Mint 13, nicméně namísto nějakého LUKSu jsem tam už tehdy používal HW šifrování umožněné rozumným BIOSem a self-encrypting SSD, takže nevím už ani jestli u 13ky (12.04) už bylo šifrování podporované instalátorem nativně. U 17 (14.04) už určitě ano.
Celkem mě překvapilo, že systém je celkem reagující i na těch nejpomalejších počítačích, na které jsem ho zkusil nainstalovat.Zkoušel jsi, jak se chová při kopírování větších dat na flashdisk? Zatím jsem ještě neviděl distribuci, která by se celá nesekala v defaultu.
Nezkousel, nenapadlo me to vubec jako nejaky test co bych mel delat. Jako je jasny ze zapis na ntfs nebo exfat je v linuxu relativne vic CPU-intensive nez nativni zapis do ext4 coz u pomalych procesoru bude citit, ale priznam se ze me to nikdy nepaadlo tohle konkretne nejak resit. Pokud budu chtit neco delat na tom Athlonu XP (a zkousel jsem na tom par hodin brouzdat po netu atd) tak mi musi byt jasne ze kdyz mam pusteny browser tak si muzu dovolit otevrit tak tri az pet zalozek maximalne a s nejakymi zurivymi alt-taby a prepinani do x dalsich aplikaci a delani nejakych I/O intenzivnich veci je potreba hodne omezovat. Kdyz ono dneska jedno okno Facebooku, druhe Gmailu, treti Google Drivu uz dost zatopi jak te RAMce tak CPU, LibreOffice6 taky neni tak usporne jako MS Office 2000 na Windows 98 ci XP a o prasackych "aplikacich" kdy jde o zaobaleny prohlizec se zavislostma v samostatnym okne (Slack apod.) co samy spolknou skoro 1 GB RAM nemluve :)
Ostatne velkou obezretnost co a kolik toho pustim soucasne jsem zvyklej delat i na tabletu (Dell Venue 11) s nejakym Atomem, 2 GB RAM, 64GB SSD a Win10Pro, tam zejmena ta RAMka je taky obrovsky limit a je treba zasadne hlidat aby to nezacalo moc swapovat, pak se na tom uz neda vubec pracovat.
Takže jednak některé prohlížeče se už ani nedělají pro 32bitové systémy, a pokud dělají, tak se nepíšou tak, aby se obešly bez procesorových instrukcí SSE2.Jak se tohle stane? Jako že je buildsystém Firefoxu tak zprasený, že když zjistí, že ho kompiluješ na x86_32, tak tam nafláká SSE instrukce i když jsi kompilátoru řekl, že je nemáš (
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz-march=686)? Bohužel to nemám kde vyzkoušet, ale disassembloval jsem binárku Firefoxu pro i386 Debian a není v ní žádná instrukce pracující s xmm registry. V libxul.so jsou, ale dost málo, takže bych řekl, že to budou speciální verze některých funkcí s runtime detekcí CPU featur.
Jak se tohle stane? Jako že je buildsystém Firefoxu tak zprasený, že když zjistí, že ho kompiluješ na x86_32, tak tam nafláká SSE instrukce i když jsi kompilátoru řekl, že je nemáš (-march=686)?Vyhozeni procesoru bez SSE2 se resilo uz pred osmi lety. Kdy se to vyhodilo realne nevim. Osobne bych tipl, ze to maji kvuli implementaci JavaScriptu, kdy se JIT dela mnohem lip, kdyz aritmetiku s plovouci radovou carku delas pres SSE2 (jako vsechno ostatni a vsude jinde) nez kdyz musis resit x87-based FPU s naprosto odlisnym pristupem...
Vyhozeni procesoru bez SSE2 se resilo uz pred osmi lety.To jsou oficiální buildy od Mozilly, ne distribuční.
Osobne bych tipl, ze to maji kvuli implementaci JavaScriptu, kdy se JIT dela mnohem lip, kdyz aritmetiku s plovouci radovou carku delas pres SSE2Samozřejmě, ale stejně tam musí být generický kód, když to jede i na ARMu i jinde.
Pokud Debian jeste dela buildy kde odstranuje pozadavek na SSE2 tak Ubuntu to uz rozhodne nedela, dokonce i samotne Ubiquity kde jsou takove ty lakadla co system bude umet je ve skutecnosti nejaky Webkit v tom okynku a ani to na tom Athlonu nefungovalo a bylo tam prazdny okno. Zajimavy je ze nepodpora SSE2 je fakt domenou predevsim webovych prohlizecu,jinak snad vsechny ostatni normalni balicky v distribuci porad funguji i bez toho.
Nova Fedora ale i v x86 buildu bude vse kompilovat s podporou SSE2 a IMHO se dalsi distra budou pridavat. Fedora je vic bleeding edge,ale Ubuntu muze byt klidne dalsi. Nicmene jelikoz 18.04 jeste vicemene funguje non-SSE a podpora byy mela byt 5 let tak to uz asi tyhle stroje nejak dozijou, byt teda otazka je jestli se postupne nebude zvysovat mnozstvi balicku co po nejake aktualizaci prestanou nahle fungovat tak jako se to uz stalo u tech prohlizecu :)
"it seems like Firefox staring with version 49.0 (released yesterday), drops supports for non SSE2 CPUs as well, like Chrome did in 2014 since 2014 (Chrome 35 was the first version to drop non SSE2 CPUs support), Firefox 48.0.2 is now the last version to work in non SSE2 CPUs" (9/2016 - https://www.vogons.org/viewtopic.php?t=50032)
tak tam nafláká SSE instrukce i když jsi kompilátoru řekl, že je nemáš (-march=686)?Taková kombinace voleb není validní:
# gcc -march=i686 -msse2 z59.c cc1: error: CPU you selected does not support x86-64 instruction setAle nevím co by udělal inline assembler přímo ve zdrojáku. Jestli tedy konfigurační systém buildu nepřeparsuje uživatelské volby (byla by to prasárna, ale třeba buildroot to dělá), tak by to mělo jít zkompilovat s -march=i686 a -mno-sse2 a fungovat.
když nefunguje swap kvůli přesouvání bloků sem a tamJá bych řekl, že problém bude spíš v tom, že při zápisu hrozí, že bude potřeba alokovat paměť - která při swapování došla.
funguje na btrfs vůbec mmap() na souborProč by nemělo? Kernelu je při obsluze pagefaultu jedno, odkud tu stránku vyčaruje.
Já bych řekl, že problém bude spíš v tom, že při zápisu hrozí, že bude potřeba alokovat paměť - která při swapování došla.Ale to bude potřeba i při swapu na loopbacku.
Kernelu je při obsluze pagefaultu jedno, odkud tu stránku vyčaruje.Aha myslel jsem si že swap bude na nižší úrovni než mmap.
Tiskni
Sdílej:
