Nezisková organizace Internet Security Research Group (ISRG) vydala Výroční zprávu za rok 2024 (pdf). Organizace stojí za certifikační autoritou Let's Encrypt, projektem Prossimo, jehož cílem je používání paměťově bezpečného kódu v kritické internetové infrastruktuře a službou Divvi Up řešící telemetrii respektující soukromí uživatelů.
Vývojáři PeerTube, tj. svobodné alternativy k videoplatformám velkých technologických společností, představili mobilní aplikaci PeerTube (Google Play, App Store). Zdrojové kódy jsou k dispozici na Framagitu.
Google představil Gemini 2.0, tj. novou verzi svého modelu umělé inteligence (YouTube).
Vývojáři KDE oznámili vydání balíku aplikací KDE Gear 24.12. Přehled novinek i s náhledy a videi v oficiálním oznámení.
Byla vydána nová verze 3.27 frameworku Flutter (Wikipedie) pro vývoj mobilních, webových i desktopových aplikací a nová verze 3.6 souvisejícího programovacího jazyka Dart (Wikipedie).
Byla vydána (𝕏) listopadová aktualizace aneb nová verze 1.96 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a animovanými gify v poznámkách k vydání. Ve verzi 1.96 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
OpenMandriva ROME, tj. průběžně aktualizovaná (rolling) edice linuxové distribuce OpenMandriva, byla vydána ve verzi 24.12.
U příležitosti oslav sedmi let prací na debianím balíčku vyšlo GPXSee 13.33. Nová verze přináší rychlejší vykreslování vektorových map a vylepšení/doladění nového stylu pro OpenAndroMaps/Mapsforge mapy. Kdo by rád OSM mapy v "prémiovém" barevném schématu a nechce čekat až nová verze dorazí do jeho distribuce, nalezne zdrojové kódy na GitHubu.
Tým Google Quantum AI představil kvantový čip Willow se 105 qubity.
Zdravím,
narazil jsem na zajímavou situaci, která sice v mé mysli dřímala už nějakou dobu, teď ji však řeším prakticky.
Plánuji postavit storage server, budou tam dva 640GB disky, které bych rád rozdělil na 3 partišny (každý) s tím, že první bude 20GB RAID1 na samotný OS, druhá 120GB RAID1/RAID10 na důležitá data a třetí 1TB RAID0 pro běžné, méně důležité věci. Nad druhou a třetí particií plánuji nahodit LVM.
Popsaná situace je snad docela běžná, když jsem však v duchu začal disky dělit, něco mě napadlo. Co když - v budoucnu - bude třeba jeden disk (v rámci jeho kolapsu) vyměnit a nový disk bude menší? Nemyslím tím 640GB versus 320GB, ale situace, kdy si výrobce nalepí na obal "640GB", ale 640,000,000,000 bajtů mít nebude.
Zkusil jsem tuto teorii na třech 80GB discích, které doma vlastním - Fujitsu, Seagate a Samsung. Zatímco Fujitsu na notebooku měl shodnou velikost se stolním Seagate (156301488 LBA sektorů), Samsung měl 156368016, což je v přepočtu na MB asi o 32 více. Napadlo mě - co bych asi dělal s RAIDy a LVM, kdybych měl najednou nějaký mirror nacpat do menší velikosti. S LVM by to snad šlo bez problému, pvmove PE trochu víc k začátku disku, zmenšení RAIDu a jede se (snad) dále. Přesto bych takové situaci chtěl předejít.
Proto se ptám; jak to řešíte vy? Necháváte na konci disku ~100MB nevyužitého místa pro tyto případy? Setkali jste se s něčím podobným? Pokud ano, jak moc velikostní odchylky souvisejí s kapacitou disků?
Předem díky za odpovědi.
No vyřeším to asi tak, že konec poslední partišny bude někde před 640,000,000,000. bajtem (zaokrouhleně) - velikost je sice různá, ale ještě jsem neviděl disk, který by šel pod hranici své specifikované velikosti.
Asi je pravda, že pak přijde na řadu terovej disk, ale pro všechny případy - těch ~40MB mě nezabije, obzvlášť na LVM s 32MB velikostí PE.
Díky všem za podněty.
Tiskni Sdílej: