Všem vše nejlepší do nového roku 2026.
Crown je multiplatformní open source herní engine. Zdrojové kódy jsou k dispozici na GitHubu pod licencí MIT a GPLv3+. Byla vydána nová verze 0.60. Vyzkoušet lze online demo.
Daniel Stenberg na svém blogu informuje, že po strncpy() byla ze zdrojových kódů curlu odstraněna také všechna volání funkce strcpy(). Funkci strcpy() nahradili vlastní funkcí curlx_strcopy().
Byla vydána nová verze 25.12.30 svobodného multiplatformního video editoru Shotcut (Wikipedie) postaveného nad multimediálním frameworkem MLT. Shotcut je vedle zdrojových kódů k dispozici také ve formátech AppImage, Flatpak a Snap.
Společnost Valve publikovala přehled To nej roku 2025 ve službě Steam aneb ohlédnutí za nejprodávanějšími, nejhranějšími a dalšími nej hrami roku 2025.
Byly publikovány výsledky průzkumu mezi uživateli Blenderu uskutečněného v říjnu a listopadu 2025. Zúčastnilo se více než 5000 uživatelů.
V dokumentově orientované databázi MongoDB byla nalezena a v upstreamu již opravena kritická bezpečností chyba CVE-2025-14847 aneb MongoBleed.
Při úklidu na Utažské univerzitě se ve skladovacích prostorách náhodou podařilo nalézt magnetickou pásku s kopií Unixu V4. Páska byla zaslána do počítačového muzea, kde se z pásky úspěšně podařilo extrahovat data a Unix spustit. Je to patrně jediný známý dochovaný exemplář tohoto 52 let starého Unixu, prvního vůbec programovaného v jazyce C.
FFmpeg nechal kvůli porušení autorských práv odstranit z GitHubu jeden z repozitářů patřících čínské technologické firmě Rockchip. Důvodem bylo porušení LGPL ze strany Rockchipu. Rockchip byl FFmpegem na porušování LGPL upozorněn již téměř před dvěma roky.
K dispozici je nový CLI nástroj witr sloužící k analýze běžících procesů. Název je zkratkou slov why-is-this-running, 'proč tohle běží'. Klade si za cíl v 'jediném, lidsky čitelném, výstupu vysvětlit odkud daný spuštěný proces pochází, jak byl spuštěn a jaký řetězec systémů je zodpovědný za to, že tento proces právě teď běží'. Witr je napsán v jazyce Go.
Jediný knoflík pro nastavení napájeníProč mi to jen přijde jako nesmysl? Uživatel který to nechce řešit se stejně do /sys koukat nemusí (nastaví to za něj distribuce) a ten, který chce rozhodně "jeden knoflík" využívat nebude.
a ten, který chce rozhodně "jeden knoflík" využívat nebude.Proč ne?
nastaví to za něj distribuceTady je právě problém. Výsledek tohohle řešení je, že to buď v distribuci nefunguje pořádně, anebo to funguje ve sytlu "každý pes jiná ves".
15.7.2010 08:29
Bedňa | skóre: 34
| blog: Žumpa
| Horňany
15.7.2010 09:16
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
Já mám btrfs na /, používám gentoo, takže tam je portage strom a další místa se spoustou malých souborů a už jsem na podobnou situaci narazil (že btrfs byl plný při ~65% využití). Ano, je stále ve vývoji, ale reiser4 se v tomhle ohledu choval vážně mnohem lépe... Samozřejmě se tyhle FS nedají porovnávat (jiné featury, návrh atd.), ale argument, že nejčastější užití bude jiné, než spousta malých souborů, mi přijde dost mimo.
15.7.2010 12:50
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
byl plný při ~65% využití
To se ale stane velmi snadno. Většina FS (výjimkou je třeba Reiser) má nejmenší jednotku blok o velikosti 4kB (nebo i jinou -- zpravidla násobně větší). Tedy, pokud tam máš soubor o velikosti třeba 5kB, tak to zabere na disku dva bloky, tedy 8kB (jeden bok plný a ve druhém 1kB, 3kB jsou tedy "ztracené místo"). Pro 2kB dat je pak potřeba velikost 4kB. Tedy takový FS by byl plný při zaplnění 2kB soubory o celkové velikosti 50% velikosti FS (resp ještě méně než 50%, protože je potřeba další místo na adresářové struktury, a obecně metadata). To je prostě vlastnost, nikoliv chyba.
FS obecně umožňují velmi malé soubory uložit úsporně přímo v adresářové struktuře (to se ale netýká velikost větší jak blok). Reiser (volba tail) jde dál (jako imho jediný), umí využít místo z nezcela zaplněného bloku. Tím sice šetří místem, ale append na takové soubory je pomalejší.
ale argument, že nejčastější užití bude jiné, než spousta malých souborů, mi přijde dost mimo.
No jenže tak to prostě je. Pokud chceš ukládat data o velikosti cca 4kB (obecně velikost bloku na FS), tak to ukládat jako jednotlivé soubory na FS není vůbec nejlepší řešení (naopak je to jedno z nejhorších).
15.7.2010 14:49
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
To je prostě vlastnost, nikoliv chyba.
Aha - v tom případě mi tyhle věci nedocházejí proto, že už od svých linuxových začátků (~6 let zpátky, nepamatuju se) používám reiser3 a reiser4 a až nedávno jsem přešel na btrfs.
No jenže tak to prostě je. Pokud chceš ukládat data o velikosti cca 4kB (obecně velikost bloku na FS), tak to ukládat jako jednotlivé soubory na FS není vůbec nejlepší řešení (naopak je to jedno z nejhorších).
No, tohle je myslím věc názoru - sám Hans viděl databáze jako řešení problémů filesystémů a chtěl, aby se to tak dělat nemuselo (proto taky pluginy pro reiser4, které měly rozšiřovat schopnosti FS na něco, co se dnes v "sémantickém desktopu" řeší kombinací FS a databáze). Nemyslím si, že pokusy o zrychlení portage přehozením metadat do sqlite jsou důkazem toho, že se FS pro tento účel nehodí, ale že se většina současných FS pro tento účel nehodí. V praxi ten rozdíl asi moc velký není (protože kdo ví, kde reiser4 skončí), ale neviděl bych správu malých souborů jako něco, co pod FS nespadá.
Nakonec ale uznávám, že FS rozumíš o dost víc - já tu jen tlumočím své dojmy z toho, co jsem kdysi od Hanse četl a taky to, že se reisery na malých souborech chovaly o dost lépe (a u těch velkých jsem nějaký velký rozdíl neviděl. Pravda, nebyly to soubory o desítkách GB na oddílech velkých v TB).
15.7.2010 15:58
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
No, tohle je myslím věc názoru...
Jasně, mezi DB a FS není žádná ostrá hranice (jak by mohla být, obojí slouží k ukládání dat).
Nemyslím si, že pokusy o zrychlení portage přehozením metadat do sqlite jsou důkazem toho, že se FS pro tento účel nehodí, ale že se většina současných FS pro tento účel nehodí.
Neznám portage ani jeho potřeby. Relační DB (sqlite je relační) obecně poskytuje pohled na data z mnoha uhlů (where přes x sloupců, join přes y tabulek) a k tomu vyžaduje spoustu režijních struktur (indexy, transakční logy, mvcc). Zatímco FS prostě vrátí data tak, jak se válí na disku, na základě jednoho identifikátoru (v relační DB bychom si pouze s primárním klíčem nevystačili). Takže na jednu stranu ano, bylo by fajn mít "DBFS" a použít jej tam, kde to má smysl, na druhou stranu ta nutná režie navíc by byla obecně neakceptovatelná. Pokud si pro portage vybrali sqlite (místo nějaké jiné a rychlejší db typu key-value), tak k tomu asi měli lepší důvod než jen jako skladiště malých souborů.
15.7.2010 16:04
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
15.7.2010 20:59
Bedňa | skóre: 34
| blog: Žumpa
| Horňany
Pokud chceš ukládat data o velikosti cca 4kB (obecně velikost bloku na FS), tak to ukládat jako jednotlivé soubory na FS není vůbec nejlepší řešení (naopak je to jedno z nejhorších).Podľa toho názoru je vidieť že sa dožijeme aj šmejdu ext999 a všetko lepšie zadupeme. Kde si myslíš že sa DB ukladá tie prťavé dáta?
16.7.2010 21:43
Bedňa | skóre: 34
| blog: Žumpa
| Horňany
16.7.2010 23:50
Bedňa | skóre: 34
| blog: Žumpa
| Horňany
17.7.2010 00:03
Bedňa | skóre: 34
| blog: Žumpa
| Horňany
17.7.2010 00:07
Bedňa | skóre: 34
| blog: Žumpa
| Horňany
normálne pôsobí len preto že možno nikto nerozpitval jeho súkromieKdyž rozpitváš soukromí téměř kohokoli, tak nebude "normální". Já teda bych si netrouf říct, že včetně soukromí jsem naprosto "normální", ty jo?
Ale pokiaľ poznáš človeka ktorého naozaj niečo nie že baví, ale úplne to žere, je to niečo ako heroin, kokain, automaty a bez dávky ...Ne, o tom jsem nemluvil, reagoval jsem na to, že duševně zdravý člověk nevynalezne něco průlomového... A čočky a silon jsou imho značně průlomové...
18.7.2010 02:23
Bedňa | skóre: 34
| blog: Žumpa
| Horňany
18.7.2010 22:34
Bedňa | skóre: 34
| blog: Žumpa
| Horňany
20.7.2010 20:56
stativ | skóre: 54
| blog: SlaNé roury
Reiser s nimi vie robiť fakt rýchloNe, neumí. Zkuste si založit řekněme 100 milionů 10-bajtových souborů s náhodnými názvy a pak je všechny přečíst. Pak to porovnejte s přečtením stejných dat uložených pohromadě v jednom 1GB souboru. Rozdíl několik řádů.
19.7.2010 12:24
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
na tieto veci sa myslelo uz davno. a ak ma niekto potrebu zaplnit disk 1KB subormi moze si tak nastavit velkost bloku (aj u 20 rocneho NTFS).
Velikost bloku si můžeš nastavit u většiny FS. To ale na principu věci (tedy zápis souborů o velikosti přibližně velikosti bloku) nic nemění. Pro soubory do velikosti bloku bude vždy průměrná ztráta 50%. Malé bloky ale způsobují velkou režii pro FS, těch bloků je zkrátka moc*, bitmapa volného místa je pak příliš velká, nalezení volného rozsahu trvá déle apod.
17% je proste "proklate" malo.
To nijak nerozporuji.
*) Záměrně nepíšu kolik je moc. Pokud se bych měl říct, kolik je moc souborů, tak na běžném desktopovém disku jsem dosáhl použitelného (opět to záměrně nechám tako mlhavě definované -- prostě "to" bylo pomalé) limitu cca 700 000 souborů na ntfs a velmi podobného 600 000 limitu na ext3. Na 3.75TiB diskovém poli s xfs těch souborů mám cca 8 900 000 a už to začíná být takové všelijaké (zejména xfs_fsr má problém najít souvislý rozsah o dostatečné velikosti, nové 20GB soubory mají běžně 1200 fragmentů, což je cca 17MB/s, což už zpomaluje kontinuální čtení). Na mailling listu xfs se lze dočíst, že rozumné maximum je 10 mil souborů (nějaký šašek chtěl na jeden FS chtěl výhledově ukládat až 500 mil. souborů, na počátku "jen" 100 mil.). Vývojáři XFS ho poslali do ... DB (tím nemyslím nutně SQL relační).
Pro soubory do velikosti bloku bude vždy průměrná ztráta 50%.Prave ze nie. Minimalne UFS/FFS deli bloky na tzv. fragmenty, ktore pouziva na kratke subory a "chvosty" dlhych suborov, cim vyznamne redukuje zmieneny problem plytvania miestom v poloprazdnych blokoch, a to zaroven pri zachovani dostatocne velkych blokov (typicky 8-16kB). Zil som v domneni, ze vsetky post-minix FS toto (alebo nejaku obdobu) robia - ak tomu tak nie je, je to pre mna dost velke prekvapenie. Uznavam, ze testovaci pripad s uniformnou starostlivo vypocitanou velkostou suboru je znacne umely. Zaroven vsak treba uznat, ze efektivita vyuzitia miesta 17%, ku ktorej tym FS dotlacil, je pre general-purpose FS neospravedlnitelna; a IMHO ospravedlnitelnych nie je ani tych 65%. Keby sa jednalo o na nieco specializovany FS a zmieneny testovaci pripad by bol proste zamerny "misuse", tak to by bolo mozne autora poslat kade lahsie. V tomto pripade to ale vyzera ako chyba. Kazdopadne tvrdit, ze BTRFS je kvoli tomu zle dizajnovany per-se je - jemne povedane - prehnane. Ako dlho trva vyladenie komplexneho FS je dobre vidiet na ZFS. BTRFS je velmi mlady a bez ohladu na slubne vyhliadky ma pred sebou este velmi dlhu cestu.
Tiskni
Sdílej:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
15.7.2010 14:21
