Po více než roce vývoje od vydání verze 5.40 byla vydána nová stabilní verze 5.42 programovacího jazyka Perl (Wikipedie). Do vývoje se zapojilo 64 vývojářů. Změněno bylo přibližně 280 tisíc řádků v 1 500 souborech. Přehled novinek a změn v podrobném seznamu.
Byla vydána nová stabilní verze 7.5 webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 138. Přehled novinek i s náhledy v příspěvku na blogu.
Sniffnet je multiplatformní aplikace pro sledování internetového provozu. Ke stažení pro Windows, macOS i Linux. Jedná se o open source software. Zdrojové kódy v programovacím jazyce Rust jsou k dispozici na GitHubu. Vývoj je finančně podporován NLnet Foundation.
Byl vydán Debian Installer Trixie RC 2, tj. druhá RC verze instalátoru Debianu 13 s kódovým názvem Trixie.
Na čem pracují vývojáři webového prohlížeče Ladybird (GitHub)? Byl publikován přehled vývoje za červen (YouTube).
Libreboot (Wikipedie) – svobodný firmware nahrazující proprietární BIOSy, distribuce Corebootu s pravidly pro proprietární bloby – byl vydán ve verzi 25.06 "Luminous Lemon". Přidána byla podpora desek Acer Q45T-AM a Dell Precision T1700 SFF a MT. Současně byl ve verzi 25.06 "Onerous Olive" vydán také Canoeboot, tj. fork Librebootu s ještě přísnějšími pravidly.
Licence GNU GPLv3 o víkendu oslavila 18 let. Oficiálně vyšla 29. června 2007. Při té příležitosti Richard E. Fontana a Bradley M. Kuhn restartovali, oživili a znovu spustili projekt Copyleft-Next s cílem prodiskutovat a navrhnout novou licenci.
Svobodný nemocniční informační systém GNU Health Hospital Information System (HIS) (Wikipedie) byl vydán ve verzi 5.0 (Mastodon).
Open source mapová a navigační aplikace OsmAnd (OpenStreetMap Automated Navigation Directions, Wikipedie, GitHub) oslavila 15 let.
Vývojář Spytihněv, autor počítačové hry Hrot (Wikipedie, ProtonDB), pracuje na nové hře Brno Transit. Jedná se o příběhový psychologický horor o strojvedoucím v zácviku, uvězněném v nejzatuchlejším metru východně od všeho, na čem záleží. Vydání je plánováno na čtvrté čtvrtletí letošního roku.
Nechám si poradit jak optimalizovat index.V PostgreSQL příkazem
REINDEX
. U MySQL nevím.
Každopádně defragmentace by ten soubor alepoň spojila dohromady.A následující zápisy ho zase budou fragmentovat. Myslím, že na udržení málo fragmentovaných souborů pro databázi musí databáze a souborový systém spolupracovat – ale nevidím důvod, co by jim v tom bránilo. Podle mne pokud bude databáze alokovat diskový prostor napřed a používat řídké soubory (tj. oznámí souborovému systému, že bude potřebovat pravděpodobně velký soubor, ale fyzicky si zatím vezme jenom část), a souborový systém bude takové soubory alokovat tak, že (pokud je místo na disku) vynechá na disku místo pro celý takový soubor, pak by k fragmentaci nemělo docházet. Samozřejmě pokud databáze zvětšuje soubor po malých blocích s tím, že souborový systém se s tím nějak vyrovná, bude soubor fragmentovaný, protože tenhle způsob využití je netypický a obecný souborový systém pro něj asi nemůže být optimalizován.
malloc
u. Tedy program by sdělil operačnímu systému délku vytvářeného souboru, OS by jej alokoval jak nejlépe by to šlo a program by pak zapisoval data.
A fragmentaci by asi nejvíc pomohlo mít databázové soubory na vyhrazeném oddílu – pak by se do těch databázových souborů nemotaly fragmenty jiných souborů a fragmentace by měla zůstat na nízké úrovni.
Abych nakonec nedopadl jako pan Ponkrác akorát bych měl oddíly dle aplikací. /www /mysql /squid
LVM samozřejmně používám .
... LV Write Access read/write LV Status available # open 1 LV Size 96.19 GB Current LE 3078 Segments 3 Allocation inherit Read ahead sectors 0 ...
Jo jo, chtělo by to nějakej LVM defrag .
Wau. Je to hodně mladá funkce, takže asi nebude moc rozšířená, ale je to krok správným směrem. Díky.
No jestli chceš mám tu jiné pikantní příklady souborů, které byly zapsány pouze jednou na oddíl o 50% zaplnění.Budu hádat - velké soubory, které se zapsaly naráz, ale stejně jsou fragmentované...
Nechávat mezi soubory volné místo (tj "fragmenovat" prázdné místo) je velmi elegantní způsob jak zabránit fragmentování samotných souborů. Zásadní chybou interního defragu ve Windows je snaha vše naplácat na jednu hromadu. Jediný defrag do Windows který umí spojit soubory a nechat místo místem je Raxco Pefrect Disk. Pak je celý proces stejně rychlý jako třeba xfs_fsr
. Velký soubor je pak samozřejmně fragmentovaný (protože je nacpán do těch volných míst), ale většinou to není nijak tragické. Pár seeků navíc při čtení mnoha GB souborů průměr rychlosti čtení moc neovlivní.
Btw. kde se to nechá stáhnout?
filefrag
? Na Fedoře jej mám v balíčku e2fsprogs
.
Na Fedoře jej mám v balíčku e2fsprogsAha, ono je to přímo v utilitách pro ext3, tak tam mě nenapadlo hledat. Jdu se stydět do kouta.
Nechám si poradit jak optimalizovat index. Tabulka byla optimalizována mnohokrát. Každopádně defragmentace by ten soubor alepoň spojila dohromady.Ten soubor by spojila dohromady...a to by se projevilo přesně jak, hm? Copak k indexovým stránkám se přistupuje sekvenčně? Není to takhle náhodou B-strom? Ten se traverzuje značně nesekvenčním způsobem. Krom toho u slušně nakonfigurovaného serveru se stejně minimálně ty indexy vejdou do paměti. "Optimalizovaná tabulka". Chm. Všichni machři na Internetu s tím slovem obratně žonglují, ale ještě z nich dostat vysvětlení, co tím vlastně mají na mysli.
Defragmentuje tuším prostým kopírováním, metodou pokus-omyl.
Ano, tohle dělá i shake. Problém je, že to nelze použít pro soubory otevřené pro zápis.
reiserfs nemá podobný nástroj vůbechm, myslel jsem si, že pro reiserfs existuje placený repacker, ale když se to pokouším googlit, tak dostávám samé nesmysly o tom, že repacker bude v reiser4, a když se to pokusím vyloučit, tak dostávám informace typu, že "ještě" nemá z mailinglistů starých sedm let apod. :-/
Tiskni
Sdílej: