Byla vydána verze 5.30 dnes již open source operačního systému RISC OS (Wikipedie).
V aktuálním příspěvku na blogu počítačové hry Factorio (Wikipedie) se vývojář s přezývkou raiguard rozepsal o podpoře Linuxu. Rozebírá problémy a výzvy jako přechod linuxových distribucí z X11 na Wayland, dekorace oken na straně klienta a GNOME, změna velikosti okna ve správci oken Sway, …
Rakudo (Wikipedie), tj. překladač programovacího jazyka Raku (Wikipedie), byl vydán ve verzi #171 (2024.04). Programovací jazyk Raku byl dříve znám pod názvem Perl 6.
Společnost Epic Games vydala verzi 5.4 svého proprietárního multiplatformního herního enginu Unreal Engine (Wikipedie). Podrobný přehled novinek v poznámkách k vydání.
Byl vydán Nextcloud Hub 8. Představení novinek tohoto open source cloudového řešení také na YouTube. Vypíchnout lze Nextcloud AI Assistant 2.0.
Vyšlo Pharo 12.0, programovací jazyk a vývojové prostředí s řadou pokročilých vlastností. Krom tradiční nadílky oprav přináší nový systém správy ladících bodů, nový způsob definice tříd, prostor pro objekty, které nemusí procházet GC a mnoho dalšího.
Microsoft zveřejnil na GitHubu zdrojové kódy MS-DOSu 4.0 pod licencí MIT. Ve stejném repozitáři se nacházejí i před lety zveřejněné zdrojové k kódy MS-DOSu 1.25 a 2.0.
Canonical vydal (email, blog, YouTube) Ubuntu 24.04 LTS Noble Numbat. Přehled novinek v poznámkách k vydání a také příspěvcích na blogu: novinky v desktopu a novinky v bezpečnosti. Vydány byly také oficiální deriváty Edubuntu, Kubuntu, Lubuntu, Ubuntu Budgie, Ubuntu Cinnamon, Ubuntu Kylin, Ubuntu MATE, Ubuntu Studio, Ubuntu Unity a Xubuntu. Jedná se o 10. LTS verzi.
Na YouTube je k dispozici videozáznam z včerejšího Czech Open Source Policy Forum 2024.
Fossil (Wikipedie) byl vydán ve verzi 2.24. Jedná se o distribuovaný systém správy verzí propojený se správou chyb, wiki stránek a blogů s integrovaným webovým rozhraním. Vše běží z jednoho jediného spustitelného souboru a uloženo je v SQLite databázi.
Aktuální verze jádra je 2.6.17.4, vydaná 6. července. Obsahuje jedinou opravu: lokálně zneužitelná zranitelnost v systémovém volání prctl(). 2.6.16.24 byla vydána se stejnou opravou.
Aktuální předverze zůstává 2.6.18-rc1. Od vydání -rc1 přibylo do hlavního jádra skoro 200 patchů; téměř všechno jsou opravy, ale byl také odstraněn algoritmus "TCP Compound" pro kontrolu zahlcení, protože existovaly pochybnosti o původu kódu.
Aktuální -mm strom je 2.6.18-rc1-mm1. Mezi nedávné změny patří velké množství nových varování ohledně nekontrolovaných návratových hodnot, sada aktualizací software suspend a nová verze sady patchů pro vektorovaný provoz I/O.
Andrew Morton se bojí, že chyby do jádra přibývají rychleji, než jsou opravovány. Ale je těžké si být jistý. Ve snaze získat trochu více informací o problému požádal Andrew LWN, aby mezi svými předplatiteli provedlo průzkum. Doufejme, že výsledky vrhnou trochu světla na to, jak vnímá širší komunita otázku kvality; diskuze o výsledcích proběhla na jaderném summitu.
Všechny tyto funkce vrací chybové kódy a my je nijak nekontrolujeme. Ale měli bychom. Takže jsem zařadil patch, který všechny tyhle věci označuje jako __must_check, což způsobuje kolem 1500 nových varování.
Jsou to všechno chyby a musí být opraveny.
-- Andrew Morton vydává 2.6.18-rc1-mm1
Zdáš se docela sebevědomý. To je dobrá vlastnost u profesionálního boxera, ale při práci s komplexním OS může být nevýhodou.
-- Ingo Molnar
Mechanismus initramfs byl přidán do jádra 2.5.46. S initramfs lze vytvořit souborový systém pro čas bootu (ve formátu cpio) a připojit jej k image souboru jádra. Když systém bootuje, má k souborovému systému přístup od samého začátku procesu bootstrapování - dlouho předtím, než se dostane do stavu, kdy bude schopný připojovat disky. Initramfs funguje podobně jako starší initrd, avšak na rozdíl od initrd nepotřebuje, aby byl systém schopen připojit disk a nalézt obraz souborového systému.
Užitečnost initramfs stoupá společně s komplikovaností hardwaru. Běžné nalezení kořenového souborového systému může mnohdy vyžadovat komplexní hardwarové nastavení, komunikaci přes síť, získání šifrovacích klíčů, sestavení RAID nebo LVM jednotek a podobně. V současné době je většina těchto úkonů prováděna v jádře, což vede k tomu, že jaderný kód duplikuje uživatelské nástroje - ale dostává se mu méně kontroly a údržby. Přesunutí této práce do uživatelského bootovacího souborového systému slibuje zmenšení jádra, větší spolehlivost procesu bootování a umožní distributorům (a uživatelům) zajímavými způsoby upravovat raný proces bootování.
Doposud však byly možnosti využití initramfs omezené; především proto, že většina kódu pro raný boot zůstává v jádře. Jednou z překážek je absence minimalistické C knihovny, která by v takovém prostředí fungovala. Ta knihovna (klibc) je pomalu vyvíjena už roky. Všechna práce nedávno vyvrcholila sadou klibc patchů, které poslal H. Peter Anvin. Klibc je teď v pozici, ze které může pomoci přepracovat linuxový boootstrap proces - a vynutit diskuzi o tom, jak by mělo jádro spolupracovat s těsně souvisejícími utilitami.
Hlavní klibc patch obsahuje náhrady za dlouhou řadu funkcí C knihovny a wrappery systémových volání. Stačí například pro podporu minimalistického shellu nazývaného "dash" a portu utility gzip. Existuje také utilita pro připojování kořenového souborového systému, která zvládá několik druhů FS, získávání IP adresy pomocí bootp nebo DHCP, NFS připojení, sestavení RAID, obnovení uspaných systémů a ještě více. Většina kódu, který se o tyto funkce stará, může být potom odstraněna z jádra. Klibc a doprovodný program kinit vypadají, že mají blízko ke stavu, kdy budou reálně využitelné.
Tento kód, podobně jako jiné snahy o přesun jaderných funkcí do uživatelského prostoru, přináší řadu otázek. Některé z nich byly probírány na jaderném summitu v Ottawě, ale skutečné řešení bude pravděpodobně vzdálenější.
Hlavní otázka je tato: jsou klibc a kinit součástí jádra? Skládají se z kódu, který býval součástí jádra, a který je nezbytnou součástí jaderného procesu bootování - bude-li tento kód z jádra odebrán, nebude možné jádro bez kinit nabootovat. Obě komponenty jsou s jádrem svázány tak pevně, že upgrade jádra může často vyžadovat i upgrade kinit a klibc. Systém, u kterého by si jádro a kinit nerozuměly, by nemusel řádně nabootovat.
Pro mnohé vývojáře jsou tyto důvody dostatečné k tomu, aby byly kinit a klibc přibaleny k jádru (a kompilovány spolu s ním). Bude-li kód držen a kompilován pohromadě, je daleko větší šance, že bude fungovat jako celek. Každá kombinace jádro/kinit bude testována společně. Kdyby byly tyto dvě části odděleny, výsledný kinit by byl velký balík jaderného kódu, který není kontrolován a spravován se zbytkem systému. Kvalita kinit by klesla, uživatelé by si stěžovali a prohlubovaly by se rozdíly mezi distribucemi.
Na druhou stranu, má-li být kinit součástí jádra, je možné se ptát, kde stanovit hranici. Mělo by být také začleněno udev, které bývalo (ojediněle) nekompatibilní s jádrem? A co uživatelský kód softwarového uspání? Utility pro členství v clusteru? Programy pro kontrolu souborových systémů? Démony pro autentizaci bezdrátových sítí? Pokud se Linux nevydá cestou BSD organizace (nepravděpodobné), nedočkáme se v brzké době zmíněných nástrojů v balíku s jádrem. Takže by - podle některých - měly být kinit a klibc spravovány jako balíčky mimo jádro, stejně jako jakýkoliv jiný uživatelský kód.
Je tu však ještě další důležitý problém: kompatibilita mezi distribucemi a různými verzemi jádra. Počátkem roku mi selhalo bootování vývojové verze jedné distribuce. Vývojáři té distribuce usoudili, že jelikož distribuční initrd připojuje /proc a /sys, není důvod, aby dělaly totéž ještě inicializační skripty. A protože jsem initrd nikdy příliš nepotřeboval, měl jsem systém, který nemohl nabootovat vanilkové jádro z kernel.org. Ta konkrétní změna byla (když jsem si stěžoval) vrácena, ale problém zůstává: kód specifický pro určitou distribuci může znemožnit spouštění jader získaných odjinud. Ted Ts'o také poukázal na inicializační problém, který na některých systémech znemožňuje spouštění aktuálních jader v RHEL4:
Kinit BY MĚLO být zařazeno do jádra a zodpovědnost za vytváření initramfs/initrd obrazu by měla být přesunuta z distributorů na proces kompilace jádra. Může a měl by existovat způsob, kterým by distribuce do initrd/initramfs přidaly své vlastní věci, ale my na sebe musíme vzít vytvoření základního uživatelského prostředí.
Jedná se o debatu, která by se mohla táhnout docela dlouho. V komunitě vývojářů existuje silná skupina, která by ráda převedla co nejvíce věcí do uživatelského prostoru. Ne každý souhlasí, že je to nejlepší přístup, ale pokud je kód vyhazován z jádra, musíme mít jasnou představu o tom, jak zařídit, aby všechny části v budoucnu dobře spolupracovaly. Taková představa zatím asi neexistuje.
Vývojáři stojící za celou řadou virtualizačních a kontejnerových projektů pokračují v práci na izolačních funkcí, které v jádře potřebují. Hodně této práce se točí kolem eliminace globálních jmenných prostorů a přídavků do systémového volání unshare(), aby se mohly zainteresované procesy uchýlit do svých vlastních soukromých jmenných prostorů. Například jmenný prostor ID procesu je na běžných linuxových systémech v současné době globální - dané ID procesu identifikuje stejný proces z pohledu všech procesů v systému. Vývojáři kontejnerů by rádi opustili globální jmenné prostory PID, aby kontejnery mohly svým uzavřeným procesům prezentovat vlastní ID procesu. Mnohé další jaderné jmenné prostory jsou měněny obdobně.
Cedric Le Goater poslal sadu patchů, která tuto práci posouvá kupředu zajímavým způsobem. De-globalizuje další jmenný prostor a přidává rozhraní pro vytváření nových jmenných prostorů. Nový typ jmenného prostoru přidaný tímto patchem je "uživatelský" - systémový pohled na hodnoty uživatelských ID. Jádro využívá uživatelská ID z větší části pro práci s právy; je mu v podstatě jedno, jestli skupina procesů interpretuje hodnoty uživatelských ID jinak než jiná skupina. Takže pokud procesy v jednom kontejneru nemohou vidět zdroje (procesy, SYSV IPC, souborové systémy) náležející jinému kontejneru, mají procesy velmi málo příležitostí ke konfliktu - i kdyby běžely se stejnou numerickou hodnotou uživatelského ID. Takové uživatelské ID může být mapováno ke dvěma zcela odlišným účtům v různých kontejnerech, přičemž izolace poskytovaná těmito kontejnery je udrží oddělené.
Jedinou malou výjimkou je struktura user_struct udržovaná v kernel/user.c. Tato struktura existuje proto, aby jádro mohlo prosazovat uživatelské limity zdrojů; kvůli tomu je jedna alokována pro každé uživatelské ID v systému. Funkce zodpovědná za vyhledání jedné z těchto struktur (find_user()) implementuje globální jmenný prostor uživatelských ID, takže procesy sdílející číslo uživatelského ID v různých kontejnerech si budou navzájem ovlivňovat limity zdrojů.
Cedrikův patch tento problém opravuje vytvořením nového typu jmenného prostoru pro uživatelská ID, což umožňuje izolaci limitů zdrojů v rámci kontejnerů. Implementace tohoto jmenného prostoru je jednoduchá, ale přesunutí procesů do nového uživatelského jmenného prostoru pomocí unshare(), snadné není. Když se proces dostane k zavolání unshare(), může mít v struktuře user_struct dlouhý seznam zdrojů. Odpojení od staré struktury bude vyžadovat, aby systém nějakým způsobem od této struktury oddělil procesem aktuálně využívané zdroje a přidal je do té nové. Tento proces je komplikovaný a náchylný k chybám. I kdyby to jednou fungovalo, mohlo by být dost obtížné kód udržovat funkční i v budoucnu.
Stejná potíž se týká jmenných prostorů SYSV IPC. Například procesu, který drží odkazy na SYSV semafor, musí být tyto odkazy odebrány, také je potřeba se správně postarat o undo informace a tak dále.
Místo pokusů o úpravy unshare() tak, aby všechny tyto záležitosti zvládala, se Cedric rozhodl pro jiný přístup: procesu je umožněno odpojení od jmenných prostorů pouze tehdy, kdy jsou všechny odkazy na tyto jmenné prostory zrušeny. To je tehdy, když proces zavolá exec() kvůli spuštění nového programu. Takže Cedric vytvořil novou formu volání execve():
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
int execns(int unshare_flags, char *filename, char **argv, char **envp);
Toto volání bude fungovat jako execve v tom smyslu, že proces spustí program uvedený ve filename s danými parametry a prostředím. Avšak nový parametr unshare_flags umožní volajícímu určit sadu jmenných prostorů, které mají být v témže okamžiku odsdíleny. Výsledkem bude, že se program spustí s čerstvými, novými jmennými prostory - bez přežívajících odkazů na ty staré. Aby se pojistilo, že vše proběhne přesně podle scénáře, execns() uzavře všechny otevřené soubory - bez ohledu na to, jestli byly označeny "uzavřít při exec".
Přesunutí tvorby jmenného prostoru do exec() se zdá dávat smysl. Vytváření jmenných prostorů je ojedinělý čin, který je proveden jako součást založení nového kontejneru; nejde o něco, o čem by si běžící procesy mohly jen tak rozhodovat. execns() umožní init v kontejneru začít s čistým štítem a zároveň to, s trochou štěstí, zjednoduší odsdílecí logiku jádra.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
24.7.2006 09:32
David Watzke | skóre: 74
| blog: Blog...
| Praha
Jestli chtějí IBM aspol dělat big iron věci, tak ať si laskavě najmou a zaplatí lidi na full-time
Eh. Jeden by si skoro myslel, že přesně tak to dělají… :-)
zeby skepsa? mozno tam povodne malo bytHodně věcí by třeba najednou bylo stabilních, no a za takovejch deset dvacet let bychom možná měli i fungující suspend na disk.Nebudeš tomu věřit, ale jsou mezi námi tací, kterým suspend funguje.
24.7.2006 10:48
vogo | skóre: 34
| blog: "Skládat papír"
24.7.2006 22:38
vogo | skóre: 34
| blog: "Skládat papír"
V takové situaci bylo čím dál více neudržitelné hrát si na "stabilní" a "vývojovou" řadu. Aspoň tak to vidím já.No a proto se na to už nehraje... Proto existují distribuční jádra enterprise linuxů, — zaplať si za stabilitu — a samotný vývoj je na druhou stranu méně obchodně závislý na exponenciálním nárůstu složitosti HW. (Kdo slyšel o 1.2 řadě na mobilních telefonech?) Kdo chce extrapolovat, ať si užije. Kdo to chce ovlivnit, ať se dá do psaní kódu :)
/usr/src/linux/Documentation/stable_api_nonsense.txt...
upřímně, kdo z vás má v serveru zvukovou kartu a používá ji?Jááá... server slouží jako fileserver, router a přehrávač mp3
tak článek si přečetlo 2315 čtenářů a Vy jste zatím jediný, kdo to tak používá. i z toho se dá soudit, že podpora zvukovek je v linuxu hlavně z jiného důvodu 
.
nicméně ty zvukovky stejně byly jen příklad, to samé lze tvrdit třeba o bluetooth, tv kartách, atd. (jasně, video lze streamovat do sítě, BT lze použít pro síťovou konektivitu, ...)
tak článek si přečetlo 2315 čtenářů a Vy jste zatím jediný, kdo to tak používá
Přestože v zásadě máte pravdu, přeci jen mi to nedá: nevíte, že je jediný, kdo ji používá. Víte jen to, že je jediný, kdo to o sobě napsal. Nebo se snad všech těch zbylých 2314 vyjádřilo do diskuse, že oni to nepoužívají? Já sice zrovna ano, ale jak tak koukám jsem jediný. Takže kdybych chtěl uvažovat podobně zkratkovitě jako vy, mohl bych prohlásit, že polovina systémáků používá zvukovou kartu v serverech… :-)
kdo z vás má v serveru zvukovou kartu a používá ji?
Já sice ne, ale někde jsem viděl zmínku o driveru, který vstup z mikrofonu používal jako zdroj entropie pro generátor náhodných čísel.
Pokud je co k čemu, driver napíše pořádně, aby se mohl stát součástí jádra... tak pravi teorie, ale co si budem povidat, ve skutecnosti je to jinak. Binarni ovladace tu jsou a nejspis jeste nejakou dobu budou. Hlavne pro hardware ktery je svym zpusobem jedinecny, takze si jeho vyrobce muze dovolit prudit s binarnima driverama. A lidi ten hw stejne budou kupovat protoze proste za to stoji. Viz nVidia grafiky nebo nektere RAID karty. A neni jen otazka jestli vendor ten driver napsat umi nebo neumi - dost casto ho proste otevrit nechce, at uz ma duvody jakekoliv. Do debaty jestli na to ma pravo nebo ne se tu nehodlam poustet. Vyrobce proste situace casem omrzi, na linux se vykasle a bude mu to fuk, protoze tech par lidi co si kvuli chybejici linuxove podpore jeho produkt nekoupi ho nepolozi. A kernelovi vyvojari se akorat budou prsit jak s nim zametli. Fakt je, ze nakonec to bude koncovy uzivatel kdo trati, protoze jeho super duper grafika v linuxu nebude nefungovat. BTW I kdyz to tak nemusi na prvni pohled vypadat taky nemam binarni ovladace rad a pokud to jde kupuju hardware ktery je nepotrebuje. Ovsem nejsem ani jejich nekompromistnim bijcem, snazim se veci videt i z jinych pohledu nez jako OSS fanatik.
Vyrobce proste situace casem omrzi, na linux se vykasle a bude mu to fuk, protoze tech par lidi co si kvuli chybejici linuxove podpore jeho produkt nekoupi ho nepolozi.Výrobce si to nemůže dovolit, pokud je nějaká konkurence, která vyrábí obdobný výrobek a ovladače dodává. Viz nVidia vs. ATI na Linuxu - když tady někdo položí dotaz, víc lidí doporučuje nVidii. Málokterá společnost si může dovolit risknout, že najednou Linuxu vzroste počet uživatelů a oni přijdou o zákazníky prostě proto, že nebudou vědět, jak ten ovladač udělat (narozdíl od konkurence, která má zkušenosti)
Výrobce si to nemůže dovolit, pokud je nějaká konkurence, která vyrábí obdobný výrobek a ovladače dodává. Viz nVidia vs. ATI na Linuxu - když tady někdo položí dotaz, víc lidí doporučuje nVidii.
Což je ale dáno spíš jejich osobními preferencemi než nějakými racionálními důvody. Co se týká novějších karet, jsou jeden za osmnáct, druhý bez dvou za dvacet. U starších karet je na tom o něco lépe ATi.
vanilkové jádro z kernel.orgTo je schválně? Nikde jsem se tím nesetkal, ale jinak se mi to líbí. Když budeme říkat, že má Linux vanilkové jádro, třeba se bude víc líbit dívkám a ženám, vanilkové jádro ve Windows nemají
24.7.2006 10:55
michich | skóre: 51
| blog: ohrivane_parky
"Vanilla" (alebo tiež "plain vanilla") je bežne používaný anglický výraz, ktorý znamená niečo ako "obyčajná verzia daného substantíva bez príkras a vylepšení"; môže sa to okrem jadra vzťahovať naozaj na všeličo, ale uznávam, že "vanilkové jadro" znie milo.
27.7.2006 03:10