Vývojáři open source operačního systému ReactOS (Wikipedie), jehož cílem je kompletní binární kompatibilita s aplikacemi a ovladači pro Windows, se na síti 𝕏 pochlubili, že ReactOS zvládne počítačovou hru Half-Life.
Byla vydána nová verze 4.8 multiplatformního integrovaného vývojového prostředí (IDE) pro rychlý vývoj aplikaci (RAD) ve Free Pascalu Lazarus (Wikipedie). Využíván je Free Pascal Compiler (FPC) 3.2.2.
Apple container dospěl do verze 1.0.0. Jedná se o open source nástroj pro spouštění linuxových kontejnerů na macOS postavený nad containerization. Napsaný je v programovacím jazyce Swift a optimalizovaný pro Apple silicon.
Bylo vydáno Eclipse IDE 2026-06 aneb Eclipse 4.40. Představení novinek tohoto integrovaného vývojového prostředí také na YouTube.
Asterinas (GitHub) je v Rustu napsané jádro operačního systému poskytující s jádrem Linux kompatibilní ABI. Vydána byla verze 0.18.0. První distribucí postavenou nad jádrem Asterinas je Asterinas NixOS. Nejedná se o oficiální projekt NixOS a nemá nic společného s NixOS Foundation.
Podrobně byla rozebrána kritická zranitelnost v nf_tables (CVE-2026-23111). Další lokální eskalace práv na Linuxu. V upstreamu byla zranitelnost již v únoru opravena. Ve zdrojovém kódu stačilo odstranit 1 vykřičník.
Evropská komise (EK) nařídila americké společnosti Meta, že musí znovu umožnit bezplatný přístup konkurenčním obecně zaměřeným asistentům umělé inteligence (AI) k WhatsAppu a tento přístup musí zachovat až do ukončení antimonopolního šetření. Opatření je dočasné a má zabránit vážnému a nevratnému poškození konkurence na rychle rostoucím trhu s obecnými AI asistenty. Meta uvedla, že se proti rozhodnutí odvolá.
Společnost Anthropic představila AI modely Claude Fable 5 a Claude Mythos 5. Claude Fable 5 je první model třídy Mythos určený pro běžné použití.
Byla vydána nová stabilní verze 3.24.0, tj. první z nové řady 3.24, minimalistické linuxové distribuce zaměřené na bezpečnost Alpine Linux (Wikipedie) postavené na standardní knihovně jazyka C musl libc a BusyBoxu. Přehled novinek v poznámkách k vydání.
Na čem pracují vývojáři v Rustu napsaného mikrokernelového unixového operačního systému Redox OS (Wikipedie)? Byl publikován přehled vývoje za květen. Vypíchnout lze nový scheduler EEVDF nebo port desktopového prostředí Xfce na Redox OS.
Na vytvoření jednoduchého repozitáře existuje nespočet nástrojů. Pro účely
tohoto článku jsem zvolil reprepro, protože nabízí jednoduché rozhraní a přesto poskytuje velmi mnoho funkcí.
Pro začátek si vytvoříme adresář, kde budeme chtít, aby reprepro pracovalo:
$ mkdir reprepro $ cd reprepro
Dále potřebujeme adresář pro nastavení:
$ mkdir conf
Minimálně musíme říci, jaké distribuce budeme v repozitáři mít, vytvoříme tedy
conf/distributions (tato ukázka obsahuje jenom jednu distribuci, ale můžeme jich použít, kolik jen chceme):
Origin: Stojan Jakotyč Label: Unofficial Packages Suite: unstable Codename: sid Architectures: i386 amd64 source Components: main contrib non-free Description: My playground
Nyní již reprepro můžeme normálně používat. Pokud jsme použili v konfiguraci
distribucí Suite, můžeme si třeba nechat vygenerovat symbolické odkazy na kódová jména:
$ reprepro -b . createsymlinks
Parametr -b určuje cestu k pracovnímu stromu reprepro, v tomto případě je to tedy aktuální adresář. Jak vidíme, reprepro už si nijak nestěžuje, takže můžeme přidat první balíček do repozitáře:
$ reprepro -b . include unstable /tmp/ukolovnik_1.0-4_i386.changes Exporting indices...
Když se nyní podíváme do pracovního adresáře, zjistíme, že se vytvořilo
několik nových adresářů a souborů. Struktura je podobná jako na jakémkoliv
mirroru Debianu - tedy adresář pool obsahuje vlastní balíčky, kdežto dists seznamy balíčků pro dané distribuce. Dále si reprepro vytvoří adresář db, kde jsou uloženy jeho interní informace o repozitáři a balíčcích.
Ručně přidávat balíčky je ale dost práce, tak je určitě lepší tento proces
zautomatizovat. Podporu už pro to reprepro má, stačí mu v souboru
conf/incoming říci, odkud si balíčky brát:
Name: incoming IncomingDir: /tmp/reprepro/incoming TempDir: /tmp/reprepro/tmp Allow: unstable>sid Default: sid
První řádek určuje jméno této fronty, můžeme použít cokoliv. Druhý adresář,
kde se fronta nachází, a třetí místo, kam se mohou odkládat dočasné soubory.
Parametry Allow a Default určují pravidla pro nahrávání balíčků. Zde tedy balíček určený pro unstable skončí v distribuci sid a všechny ostatní také v distribuci sid. Zpracování pak spustíme následujícím příkazem, případně ho můžeme dát do cronu a nechat frontu zpracovávat automaticky:
$ reprepro -b . processincoming incoming Exporting indices... Deleting files no longer referenced...
Pokud Debian používáte již nějakou chvíli, asi víte, že program apt-file umí vyhledávat v seznamech souborů nenainstalovaných balíčků. Aby to ovšem fungovalo, musí být v repozitáři seznam souborů v balíčcích (soubor Contents). Program reprepro umí generovat i tento seznam, stačí zapnout tuto volbu v conf/distributions. Když už budeme v tomto souboru něco měnit, můžeme ještě zapnout bz2 kompresi pro všechny seznamy:
DebIndices: Packages Release . .gz .bz2 DscIndices: Sources Release . .gz .bz2 Contents: . .gz .bz2
Pokud máme pocit, že by se balíček mohl hodit i někomu dalšímu, tak je dobré ho dostat do distribuce. Jakékoliv nové balíčky musejí před přijetím projít frontou nových balíčků, kde čekají na to, až je správce ftp repozitáře zkontrolují a přijmou do distribuce. Po této kontrole už není nahrávání nových verzí omezeno.
Než se však pokusíme dostat náš výtvor do distribuce, měl by být balíček v co
nejlepším stavu, abychom ušetřili práci sobě i dalším lidem, kteří se s
balíčkem budou muset poprat. Pro základní kontrolu poslouží lintian popsaný dříve v seriálu, ale nemalou pozornost bychom měli věnovat také licencím
jednotlivých souborů a jejich popisu v debian/copyright.
Když si myslíme, že máme vše správně, můžeme pokročit k nahrávání. Jako naprostý nováček máme možnost jen si nechat balíček nějakým vývojářem nahrát do distribuce. Tomuto se říká sponzorování a sponzor je zodpovědný za kvalitu balíčku, přestože se o něj stará někdo jiný. Poté, co získáme dostatek zkušeností, je možné se pokusit postoupit na vyšší úroveň a stát se Debian maintanerem, kdy už můžeme nahrávat svoje balíčky samostatně. Další možností k růstu je Debian developer, kdy již můžeme do distribuce nahrávat cokoliv (samozřejmě při dodržování daných pravidel).
Jak již jsem napsal dříve, sponzorování balíčku je zpočátku jediný způsob, jak dostat balíček do distribuce. Nejtěžším úkolem je (hned po vytvoření bezvadného balíčku) nalezení vývojáře, který bude ochotný balíček zkontrolovat a nahrát do distribuce. Pro tento účel nám poslouží server http://mentors.debian.net, kam balíčky pro sponzory můžeme nahrávat, a mailing list debian-mentors, na kterém se pokusíme nalézt sponzora.
Lidí hledajících sponzora pro svůj balíček je hodně a čas vývojářů je omezený, takže je nutné zaujmout a dobře odvést svojí práci. Pokud se snažíme do distribuce dostat stopadesátý editor, tak určitě budeme mít mnohem těžší pozici, než při práci s nějakým zajímavým nástrojem nebo hrou. Snažte se proto při psaní mailu myslet na to, že musíte někoho zaujmout a uvést všechny relevantní informace, které by sponzor mohl potřebovat (na stránkách mentors.debian.net si můžete zkopírovat šablonu, která bude všechny potřebné informace obsahovat).
V prvních balíčcích budou obvykle snadno dohledatelné chyby, takže když má někdo k našemu balíčku připomínky, jedná se většinou o dobře míněné rady; snažte se jimi řídit. Nicméně se nebojte diskutovat o případných alternativních řešeních, nikdo není neomylný. Většina sponzorů má seznam věcí, které kontrolují, jeden z nich je například Checklist for sponsored packages. Občas nebývá od věci si takový seznam projít ještě před předhozením balíčku na mailing list a jeho veřejným pranýřováním :-).
Pokud už se s nějakým sponzorem dohodneme na jednom balíčku, obvykle bývá i přístupnější nahrávání našich dalších balíčků, ale nemusí to být pravidlem.
V současné době je poměrně velká část balíčků spravována v týmech. Jedná se o poměrně snadnou možnost, jak spravovat balíček bez toho, aby se člověk musel stát Debian maintainerem nebo developerem nebo musel složitě shánět sponsora, protože se v týmu snáze najde nějaký Debian developer, který balíček nahraje. Jinak se jedná o stejný případ jako sponzorování.
Pokud už máme za sebou nějakou práci na sponzorovaném balíčku, můžeme zkusit
za tento balíček kompletně převzít zodpovědnost a stát se Debian maintainerem.
Když se jím staneme, můžeme nahrávat svoje balíčky, které sponzor nahraje do
distribuce s nastaveným příznakem DM-Upload-Allowed. Informace o tom, jak se stát Debian maintainerem, najdeme na wiki.debian.org/Maintainers.
Jako Debian developer už můžeme nahrávat do distribuce cokoliv a musíme tedy splnit o něco přísnější podmínky. Nicméně tento postup je jasně definovaný a při troše štěstí není problém ho celý absolvovat během půl roku.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej: