Byla vydána (𝕏) nová major verze 17 softwarového nástroje s webovým rozhraním umožňujícího spolupráci na zdrojových kódech GitLab (Wikipedie). Představení nových vlastností i s náhledy a videi v oficiálním oznámení.
Sovereign Tech Fund, tj. program financování otevřeného softwaru německým ministerstvem hospodářství a ochrany klimatu, podpoří vývoj FFmpeg částkou 157 580 eur. V listopadu loňského roku podpořil GNOME částkou 1 milion eur.
24. září 2024 budou zveřejněny zdrojové kódy přehrávače Winamp.
Google Chrome 125 byl prohlášen za stabilní. Nejnovější stabilní verze 125.0.6422.60 přináší řadu oprav a vylepšení (YouTube). Podrobný přehled v poznámkách k vydání. Opraveno bylo 9 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Textový editor Neovim byl vydán ve verzi 0.10 (𝕏). Přehled novinek v příspěvku na blogu a v poznámkách k vydání.
Byla vydána nová verze 6.3 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Přehled změn v příslušném seznamu. Tor Browser byl povýšen na verzi 13.0.15.
Dnes ve 12:00 byla spuštěna první aukce domén .CZ. Zatím největší zájem je o dro.cz, kachnicka.cz, octavie.cz, uvycepu.cz a vnady.cz [𝕏].
JackTrip byl vydán ve verzi 2.3.0. Jedná se o multiplatformní open source software umožňující hudebníkům z různých částí světa společné hraní. JackTrip lze instalovat také z Flathubu.
Patnáctý ročník ne-konference jOpenSpace se koná 4. – 6. října 2024 v Hotelu Antoň v Telči. Pro účast je potřeba vyplnit registrační formulář. Ne-konference neznamená, že se organizátorům nechce připravovat program, ale naopak dává prostor všem pozvaným, aby si program sami složili z toho nejzajímavějšího, čím se v poslední době zabývají nebo co je oslovilo. Obsah, který vytváří všichni účastníci, se skládá z desetiminutových
… více »Program pro generování 3D lidských postav MakeHuman (Wikipedie, GitHub) byl vydán ve verzi 1.3.0. Hlavní novinkou je výběr tvaru těla (body shapes).
Aktuální vývojová verze jádra je 3.14-rc5 vydaná 2. března. Linus k ní řekl: Nic moc tam není. A tak to mám rád. Ozkoušejte, jestli vám funguje.
Stabilní aktualizace: během minulého týdne žádné nevyšly. Aktualizace 3.13.6 a 3.10.33 se aktuálně revidují; jejich vydání můžeme očekávat 6. března nebo později.
Řekl bych, že tohle je ten zlom mezi „jsi blázen, že ukazuješ zdrojový kód pro své GPU a riskuješ soudní spory“ a „jak se chceš udržet na trhu bez svobodného ovladače“.
Jelikož nikdo nemá o tento kód takový zájem, aby jej udržoval, tak si myslím, že bychom jej měli vyhodit namísto toho, abychom uživatelský prostor uváděli v omyl, že tento kód funguje a fungovat bude nadále.
Zdá se, že i Red Hat má projekt pracující na patchování běžících jader. kpatch vám umožňuje patchovat jádro bez restartu systému nebo jakýchkoliv procesů. To umožňuje administrátorům nasadit do jádra kritické bezpečnostní záplaty ihned, bez nutnosti čekat na doběhnutí dlouho běžících úloh, odhlášení uživatelů nebo naplánovaný čas pro restart. Máte lepší možnost udržet si systém v provozu bez nutnosti obětovat bezpečnost či stabilitu. Vypadá to, že má blíže ke ksplice než SUSE kGraft, jelikož patchuje kompletní funkce.
Libby Clark připravila rozhovor s Vojtěchem Pavlíkem, ředitelem SUSE Labs, a to na téma kGraft. V tomto rozhovoru se dozvíme více o projektu na patchování jádra za běhu kGraft od SUSE; jak se patche kGraft spojují s linuxovým jádrem; jak se odlišuje od jiných řešení pro patchování za běhu; jak budou moci vývojáři používat následující vydání; a jak projekt komunikuje s jadernou komunitou, aby byl přijat v upstreamu.
Broadcom oznámil vydání zdrojového kódu a dokumentace pro svůj grafický subsystém VideoCore IV. Tento subsystém je mimo jiné k nalezení v procesoru Raspberry Pi. Za poslední desetiletí se trend v oblasti desktopové grafiky naklonil k větší otevřenosti a nejinak je tomu v oblasti mobilní. Broadcom – lídr v oblasti grafických procesorů – stojí v čele těchto změn a snaží se k nim přispět.
Návrh systémových volání není nikdy snadný; často se najdou překvapivé krajní situace, na které vývojáři při přípravě rozhraní zapomněli. Obzvláště pak systémová volání pro práci se systémy souborů se zdají být k těmto problémům náchylná, jelikož složitost a rozmanitost implementací systémů souborů znamená, že se může objevit řada překvapení číhajících na vývojáře, který chce vytvořit novou operaci nad soubory. Některá tato překvapení se vynořila během diskuze o plánovaném rozšíření systémového volání fallocate().
fallocate() se zabývá alokací prostoru v souboru; jeho počátečním cílem bylo umožnit aplikaci alokovat bloky v souboru před zápisem. Tento způsob předalokace zajistí, že bude k dispozici dostatek místa, ještě než se pokusíme zapsat data; implementacím systémů souborů to také může pomoci efektivněji rozložit alokované místo na disku. Později byla přidána operace FALLOC_FL_PUNCH_HOLE pro dealokaci bloků v souboru, která po sobě nechává díry.
V únoru navrhl Namjae Jeon novou operaci fallocate(); jeho návrh obsahoval implementace pro ext4 a xfs. Podobně jako operace vytváření děr odstraňuje data ze souboru, ale je tu jeden rozdíl: místo zanechání díry tato operace přesune všechna data za dotčenou oblastí na její začátek, čímž je celý soubor zkrácen. Prvním případem využití by mohlo být rychlé a efektivní odstranění části video souboru. Pokud je odstraňovaná oblast zarovnaná na bloky (což by alespoň na některých systémech souborů bylo vyžadováno), pak by odstranění mohlo vést jen ke změně mapy extentů souboru bez jakéhokoliv kopírování dat. Jelikož soubory s videem mohou být velké, není divu, že by efektivní operace pro „vyjmutí“ byla zajímavá.
Nuže, jaké otázky vyplývají při takové operaci na povrch? Mohli bychom začít interakcí se systémovým voláním mmap(), které mapuje soubor do adresního prostoru procesu. Navržená implementace odstraňuje všechny stránky od dotčené oblasti až na konec souboru z cache stránek; špinavé stránky jsou nejprve zapsány na disk. Toto zabrání okamžité ztrátě dat, která mohla být zapsána přes mapování, a zbaví se jakýchkoliv stránek, které po dokončení operace budou za koncem souboru. Mohlo by to ale být překvapivé pro proces, který neočekává ve svém mapování posuny konce souboru; Dave Chinner ale říká, že aplikace používající operaci zhroucení souboru (collapse) obvykle ke svým souborům nepřistupují přes mmap(). Navíc by aplikace překvapené náhlým zkrácením souboru obvykle nebyly schopné řešit ani jiné úpravy, i kdyby tato operace nebyla k dispozici.
Jak ale Hugh Dickins upozornil, je tu jeden související problém: na systému souborů tmpfs jsou v cache stránek všechny soubory a vypadají dosti jako mapování do paměti. Jelikož cache stránek je pro tmpfs úložištěm, tak odstranění stránek z cache stránek nepovede ke šťastnému konci. Dříve než tedy tmpfs začne tuto operaci podporovat, bude nutné věnovat více úsilí do správné podpory cache stránek. Hugh si nebyl jist, jestli bude někdy potřeba tuto operaci na tmpfs podporovat, ale podle jeho vlastních slov vyřešení problémů s cache stránek na tmpfs pravděpodobně povede k robustnější implementaci i na jiných systémech souborů.
Hugh také dumal nad tím, zda bychom namísto jednosměrné operace „zhroucení“ neměli mít operaci obousměrnou:
Z názvu ZHROUCENÍ [collapse] jsem trochu smutný, ale po sedmi měsících je trochu pozdě si stěžovat. Překvapuje mě, že odvádíte všechnu tuto práci pro zmenšení souboru, aniž by existovala odpovídající operace nafouknutí – dá se čekat, že všichni inzerenti, jejichž reklamu umazáváte, se brzy vrátí s tím, že chtějí nafukování, aby ji měli zase kam vrátit.
Andrew Morton na to navázal návrhem, že byl bylo možná nejlepší všeobecné systémové volání přesuň tyto bloky odsud tam. Davevovi se to ovšem moc nezamlouvalo, má totiž obavy, že by to bylo složité a plné různých krajních situací:
Jinými slovy, zhroucení rozsahu je jednoduchá operace, „přesuň libovolné bloky odsud tam“ je noční můra jak z hlediska specifikace, tak implementace.
Andrew nesouhlasil; říká, že obecnější rozhraní by bylo lepší a že problémy je možné překonat, ale nikdo jej v tomto názoru nepodpořil. Proto je pravděpodobné, že operace zůstanou omezené na zhroucení částí souborů; dodatečná operace „vložení“ může být přidána v budoucnu, pokud by se pro ni našlo využití.
Mezitím se objevila další otázka ohledně chování volání; co se stane, pokud odstraňovaný obsah dosahuje konce souboru? Současná podoba patche v takovém případě vrací EINVAL s tím, že by místo toho měl být použit truncate(). Ted Ts'o se zeptal, zda by neměly tyto operace být převedeny přímo na volání truncate(), ale Dave je proti. Operace zhroucení, která zahrnuje konec souboru, je podle něj nepochybně chybou; v takové situaci je lepší chybu vrátit.
Jsou tu ale i zajímavé bezpečnostní problémy, pokud by operace zhroucení směla obsahovat konec souboru. Systémy souborů mohou alokovat bloky za koncem souboru; o toto lze požádat pomocí fallocate(). Tyto bloky obvykle nejsou systémem souborů vynulovány; místo toho jsou aplikacím nepřístupné, takže stará data tam uložená nejsou nikdy čtena. Pokud by si programátoři nedali pozor, pak by implementace zhroucení, která umožňuje jít za konec souboru, mohla zpřístupnit tato stará data, hlavně kdyby operace byla přerušena (například pádem systému). Než abychom na vývojáře systémů souborů líčili takovou past, Dave by raději riskantní operace rovnou zakázal, hlavně když není znám žádný důvod, proč je podporovat.
Výsledkem diskuze je tedy to, že operace FALLOC_FL_COLLAPSE_RANGE půjde do jádra v podstatě beze změny. Nebude mít všechny schopnosti, které by vývojáři rádi viděli, ale nabídne jednu užitečnou funkci, která by určitým aplikacím mohla pomoci na výkonu. Zda to bude stačit i do budoucna, se ještě ukáže; návrh API systémových volání je obtížný. Pokud by ale někdy byly potřeba dodatečné funkce, pak je můžeme zařadit pomocí nových povelů FALLOC_FL při současném zachování kompatibility.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
Linus k ní řekl: Nic moc. A tak to mám rád.
"Nic moc" zní jako že to RC nestojí za moc. V tomhle kontextu Linus IMHO myslel spíš něco jako "není toho moc" (změn oproti předchozímu RC).
Vypadá to, že více blíže ke ksplice než SUSE kGraft
více → má?
24.3.2014 13:50
little.owl | skóre: 22
| blog: Messy_Nest
| Brighton/Praha
24.3.2014 13:52
little.owl | skóre: 22
| blog: Messy_Nest
| Brighton/Praha
25.3.2014 00:21
Max | skóre: 72
| blog: Max_Devaine
.Takze se trebas nejdriv musis dostat aspon do interni site, coz se trebas nedostanes, protoze prave ten srv kterej by ti to umoznil jaksi nenastartoval ...Ne každej je takovej blázen, aby takový server měl jenom jeden.
26.3.2014 08:45
Max | skóre: 72
| blog: Max_Devaine
Mezi nama, chtel bych videt silence, kterej by zcela jakkoli (a to mluvim samo i o aplikacich) patchoval produkcni system "za chodu".
Ve skutečnosti kGraft vznikl jako reakce na zcela reálnou a hmatatelnou poptávku ze strany významných enterprise zákazníků - a pochybuji, že v případě kpatch to bylo jinak.
Samozřejmě si to ale nelze představovat tak, že se bude za běhu patchovat všechno. Tohle je mechanismus primárně cílený na dočasné opravy nejkritičtějších chyb na systémech, u kterých by případný downtime byl velmi náročný a/nebo nákladný.
To zjistis az se neco podela, pripadne az ti po vypadku elektriky system nenastartuje (coz casto potesi jeste vic, jet nekam par set km ...)
U systémů, o kterých se bavíme, je samozřejmostí zálohované napájení a obvyklá je i remote console. Nemluvě o tom, že jakmile už by z jakéhokoli důvodu došlo k rebootu, je to příležitost nahradit live opatchované jádro řádným updatem.
kdykoli cokoli patchuju ja, tak si to nejdriv vyzkousim na testovacim strojiA na téhle technice se s použitím jaderných patchů něco mění?
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
24.3.2014 14:12