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 nadále 3.6-rc3, od minulého týdne žádné další -rc verze nevyšly.
Stabilní aktualizace: verze 3.0.42, 3.4.10 a 3.5.3 vyšly 26. srpna s obvyklou hromadou oprav. Ve verzích 3.0.42 a 3.4.10 se vyskytly potíže s grafikami Intel, takže pozor na ně.
Někdo se snaží pozabíjet vývojáře jádra.
Nejprve jsme tu měli dvě zemětřesení – Bůh asi tento týden nenávidí nejen republikány, ale i nás jaderné vývojáře. Jenže my se zastrašit nenecháme a kvůli zemětřesení o síle 5,5 jen trochu zafňukáme a na chvilku se schováme do skříně.
Ale po chvíli krčení ve skříni zaklepali na dveře pořadatelé a začali rozdávat skateboardy s nevinným vysvětlením "Jsme přece v San Diegu."
Pokud to není znamení, že se nás někdo snaží zabít, pak teda nevím.
Co se Linuxu týče, tak Linus Torvalds evidentně nevynucuje svá vlastní autorská práva přes [Software Freedom] Conservancy, ale nedávno jsem se ho na jedné akci zeptal: „Nevadí ti, že vynucuji GPL u Linuxu?“ Linus odpověděl: „Ne. Pravdou je, že jedním z důvodů, proč u Linuxu nevyžaduji přiřazení autorských práv, je to, že jsem chtěl, aby o osudu svých práv rozhodovali vývojáři sami“. Mnoho držitelů práv u Linuxu v této věci s Conservancy spolupracuje v souladu s Linusovým postojem, že o svých právech mají rozhodovat sami.
-- Bradley Kuhn
Většina lidí soubor feature-removal-schedule.txt ignoruje, vyjma těch, co do něj něco přidávají. Je to spíš něco jako globální TODO pro vývojáře než cosi užitečného pro každého.
Zařaďte pořadavek na odstranění souboru feature-removal-schedule.txt.
Ben Hutchings oznamuje: Mám v plánu Linux 3.2.y udržovat alespoň tak dlouho, jako bude podporován Debian 7.0. End-of-life pro každé vydání Debianu je 1 rok po následujícím vydání, takže to bude asi tak do konce roku 2015.
Jaderný summit 2012 trval tři dny (od 27. do 29. srpna) a konal se v San Diegu. Podíváme se na vybraná témata.
Už několik let Rafael Wysocki sleduje regrese v jádře a vytváří seznamy a statistickou analýzu. Tato práce, která má za výsledek (nepřesné) údaje o zvyšování nebo snížování kvality následujících vydání jádra, byla něčím, co ostatní vývojáři jádra na Jaderném summitu vždy ocenili. Jeho přednáška v první den Jaderného sumitu ale byla letos poněkud odlišná. Zajímal se o to, jak by budoucnost sledování regresí měla vypadat.
Postupem času se totiž Rafael postupně přesunul k jiným pracem v jádře a zbývalo mu tak méně času na sledování regresí. Tou dobou se pár dalších lidí naštěstí přihlásilo, že budou vytvářet a spravovat souhrnná hlášení z Bugzilly, která jsou používána ke sledování regresí. Bohužel to ale nešlo moc dobře. Rafael už dříve poznamenal, že jaderná Bugzilla není pro toto moc vhodná. Po odchodu Rafaela se navíc ukázalo, že ne všichni mají stejný názor na to, jak by k tomuto měla Bugzilla být používána. Tyto neshody nakonec byly jedním z důvodů, proč Rafaelovi následníci přestali na sledování regresí pracovat.
Tím se dostáváme k současné situaci: už skoro půl roku nikdo regrese nesleduje. Navíc Rafael poznamenal, že vzhledem ke svým ostatním závazkům se nebude moci k této práci v budoucnu vrátit. To jej vedlo k jednoduché otázce: chceme regrese dále sledovat?
Právě v tento moment se ozvalo mnoho vývjářů, kteří vyjádřili, jak důležitá jim Rafaelova práce přišla. H. Peter Anvin například řekl, že sice není fanouškem Bugzilly ale přehled regresí mi přišel užitečný. Přinutilo mě to pracovat na věcech, na kterých se mi dělat nechtělo. Linus Torvalds navíc rovněž řekl, že si cenil přehledu, který mu Rafaelova práce poskytovala.
Diskuze se odklonila k jiným tématům. Rafael přemýšlel o tom, jestli je Bugzilla vůbec ke sledování a řešení chyb v jádře užitečná. Odpovědi vývojářů se lišily podle konkrétního subsystému, některé na ni dosti závisí, jinde se zase preferuje e-mail. James Bottomley upozornil, že Bugzila umožňuje lidem, kterým mailing list nic neříká, zadat bug do Bugzilly a ten se pak automaticky objeví v mailing listu. Bugzilla tak těmto uživatelům umožňuje komunikovat s vývjáři v souladu s jejich pracovními postupy. Později toto vedlo Rafaela k jinému problému: když některé subsystémy používají Bugzillu, zatímco jiné zase mailing listy nebo jiné mechanismy, co by lidem, co nahlašují chyby, měli vývojáři říci o správném způsobu? Tato otázka je pro lidi, co hlásí chyby poprvé, docela překážkou. Bohužel nebylo moc času se tímto zabývat hlouběji.
Dále pak proběhly další diskuze o tom, jak by se Bugzilla měla ke sledování regresí používat a zda na to nejsou lepší nástroje, žádné konkrétní alternativy ale navrženy nebyly. Nakonec se přítomní shodli, že na nástroji až tak nesejde a volba nástroje by měla zůstat na tom, kdo se od sledování bude starat.
Stále tu tedy je volné místo pro jednoho nebo více lidí, kteří se o sledování regresí postarají. Práce je to sice ceněná, nicméně neplacená.
H. Peter Anvin zahájil svou přednášku slovy, že Linux podporuje neuvěřitelné množství hardwaru. Zejména nabízí dlouhou podporu pro starší hardware a právě díky tomu je u některých uživatelů tak populární. Většinou je podpora starého a neobvyklého hardwaru a toolchainů záslužná. Petrova otázka nehledě na toto zněla: jaká omezení na úsilí věnované podpoře starých či neobvyklých hardwarových architektur, toolchainů a zařízení chce vývojářská komunita určit?
Peterovi jde o to, že podporování starých a podivných systémů s sebou nese značné úsilí a obtíže. Když jde o podporu takových systémů, je nutné zvážit toto: na těchto systémech záleží jen malému množství uživatelů, jenže jejich podpora ztěžuje práci napříč celou komunitou.
Peter uvedl několik příkladů. Jádro stále obsahuje kód pro podporu starých procesorů Intel 386 (předchůdce 486 z roku 1989). Spouští ještě někdo Linux na tak starém hardwaru? Peter prohlásil, že jako správce x86 nedavno přijal hlášení chyby od uživatele, který se na takovém systému pokoušel Linux spustit. Zrod tohoto hlášení je ale zajímavý. Pocházelo totiž od někodo, kdo se sám sebe ptal, jestli půjde moderní linuxové jádro vůbec ještě nastartovat na obdobně starém stroji. Peterova otázkou tedy je: má se komunita ještě snažit toto podporovat?
S podporou starých systémů se pojí různé komplikace. Správce například může chtít udělat změny, které mohou mít vliv na staré systémy, ale může být nesnadné zhodnotit, jaký dopad mohou mít. Navíc je nepravděpodobné, že tento správce bude mít po ruce hardware, aby to otestoval. Legacy kód je tedy jen málokdy spouštěn a v takovém kódu se mohou ukrývat chyby a bezpečnostní díry. (Peter upozornil, že „háčky“ specifické pro architektury jsou „běžným“ řešením, jak podporovat podivné architektury. Tyto háčky jsou pak kódem ve stylu COMEFROM, o kterém je obtížné se pak rozumně bavit. Jediným řešením je důsledné dokumentování prekondicí, postkondicí a invariantů takového háčku. Asi nepřekvapí, že pravděpodobnost výskytu takové dokumentace je někde mezi výjimečně a nikdy.
Je tu několik otázek, které by měl člověk zvážit, když jde o to pokračovat v podpoře starého systému. Kupříkladu jestli nějací uživatelé tohoto systému vůbec ještě jsou, kolik jich je a hlavně, jestli má smysl je podporovat v nových jádrech? Průšvih je, že u obskurních systémů je těžké odpovědi na tyto otázky získat. Peter hlavně zpochybnil domněnku, že bug reporty znamenají, že tu jsou aktivní uživatelé.
Staré nástroje pro sestavování představují obdobný problém. Peter řekl, že Lidé si stěžují, když uděláme něco, co vyvolá chybu v 7 let starém toolchainu. Jednoho dne prostě musíme říct: pokud chcete používat nové jádro, musíte být připraveni nainstalovat si náležitý toolchain..
Peter rozšířil debatu o starých systémech na rozhraní pro uživatelský prostor. Jako příklad posloužil kód pro kompatibilitu, který už dlouho není používán. Jde například o podporu a.out na x86-64, což bylo zdrojem několika závažných bezpečnostních chyb; jenže formát a.out byl v době příchodu architektury x86-64 zastaralý a pravděpodobně se mu nedostalo ani žádného použití. Má nějaký smysl takto stará rozhraní podporovat a existuje vhodný způsob, jak je označit za zastaralá a odstranit je?
V tento moment se o slovo přihlásil Linus: Nikdy jsem netvrdil, že nemáme měnit ABI. Už jsme to kvůli opravě chyb udělali. Hlavně jen neporouchejte uživatelský prostor. Pokud můžeme změnit ABI a nikdo si na to nestěžuje, tak směle do toho. Jako mezikrok v procesu odstraňování Rusty Russel navrhl přidání volby CONFIG_MODERN, která by byla standardně zapnutá a mohla by být vypnuta, pokud někdo potřebuje zastaralé funkce. Len Brown odpověděl, že by se tomu asi dostalo podobného osudu jako CONFIG_EXPERIMENTAL, které je vždy zapnuté (CONFIG_MODERN by tedy ve výsledku asi bylo distributory vždy vypnuto). Thomas Gleixner místo toho navrhl, aby staré funkce byly skryty pod volbami označenými jako „bool n“, což by bránilo jejich vybrání, a pak by po rozumné prodlevě mohlo dojít k odstranění, když si nikdo nebude stěžovat.
Debata skončila bez jasných závěrů, ale pár lidí se vyslovilo pro odstranění podpory zastaralých systémů, aniž by proti tomu někdo zásadně protestoval. Proto se tedy může stát, že brzy budeme svědky aktivit s cílem vyčistit jaderný kód od systémů, které už nemají žádné využití.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
H. Peter Anvin[joke] Osobně bych odstranil všechen x86 kód
[/joke]
Kdyby existovala udržovaná větev pro tyto systémy, tak bych řekl skoro bez zaváhání Ano, ale i386 systémy pořád mohou existovat. Například jako opencore projekty a tam není jistota, že někdo implementuje pentium like core. Jinak 386 se od 486 liší minimálně (jen podpora writeback cache a CPUID u některých modelů a asi dvou až tří užitečných instrukcí), takže vyhození i386 by se mohlo dotknout i 486 strojů, což bych nerad, protože 486 je z x86 můj nejoblíbenější model (relativně. Absolutně je to fušeřina ). Hlavně tu taky pár 486 strojů mám a nejsou zrovna zakonzervovaný ve vitrínce.
podpora … a asi dvou až tří užitečných instrukcí
Jednou z nich je ale cmpxchg, která je zrovna dost důležitá.
.
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
xchgadd.
Nojo fakt:
flags : fpu tsc cx8
Myslíte, že by dovolil vmware Xpečkům ošahat si procesor nebo dokáže tyto rozšíření nějakým způsobem emulovat a instalace by pokračovala dál jako by se nechumelilo? :) Já myslím, že by též zkiksovala :)
20.9.2012 17:13
stativ | skóre: 54
| blog: SlaNé roury
21.9.2012 12:32
stativ | skóre: 54
| blog: SlaNé roury
17.9.2012 12:06
Jendа | skóre: 78
| blog: Jenda
| JO70FB
Například jako opencore projekty a tam není jistota, že někdo implementuje pentium like core.Proč by open-source procesor implementoval zrovna x86?
. (+ spousta 8080 implementací)
Nicméně (viz zet86) je otázka zda se někdo odhodlá k plnému 386 (32b, stránkování, chráněný mód). Protipříklad, takovej Vortex prej dělal i586 kompatibilní procesory, ale bez FPU, což je stav stejný jako u 386 nebo u hodně prvních 486.
My jsme tehdy napoprvé od toho chtěli základní běh a laditelnost Cčkových programů, bez potřeby složitého portování(na ARM)/cross-kompilace/cross-ladění, plus podporou WiFi v MiniPCI slotu (nové jádro bylo hlavně kvůli tomu).
Taky už jsem zkoušel provozovat na Vortexu nějaký softwarek v Perlu, nepříliš složitý - a jenom start Perlu 5 na Vortexu z CF karty je docela tragédie. Trvalo mi asi 20 vteřin, než se program rozběhl (= load z disku + překlad zdrojáku do interního syntaktického stromu). Možná to souvisí spíš s IOPS té CF karty, než s výkonem procesoru při kompilaci zdrojáku. On ten softwarek používal docela velké knihovny jako Expect, Switch a POSIX(termios) - spoustu malých souborků v /usr/lib/perl5/*
Pokud se týče práce v kernelu, považuju se taky za učedníka/začátečníka - a přesně proto se ARMu vyhýbám obloukem. Už jsem potkal pár lidí, kteří se o Linux na ARMu pokusili, byli o ligu výš než já, a většinou dost naříkali.
Taky mi prijde, ze pokud uz nekdo nakoduje cely virtualni rezim u 386, tak uz tam tech par instrukci, co ma navic 486, muze snadno dodelat...Pokud by podpora 486 zůstala, tak by se mě to asi nedotklo. Ale bál bych se, že by po krátkém čase chtěli zaříznout třeba i 486 a toby už byl problém.
Mimochodem, 486 se vyrabely v SMP konfiguraci, ze je ta cmpxchg() tak dulezita?Jj přesně tohle mě napadlo taky
. Samotná 486 to nepodporuje, myslím, že by byl nutnej hodně speciální čipset. Jediný o čem vím je NCR Voyager, kde je prý stále podpora v kernelu pro cca 3 lidi na světě . Doufám, že jim to podporu neukončí, pokud by se v kernelu dohodli na odstranění podpory.
Jinak je otázka do jaké míry se cmpxchg používá i pro atomické operace na jednom CPU, třeba chtějí v linuxu všude použít cmpxchg. Jako cmpxchg se totiž přímo jmenujou linuxové lowlevel funkce pro atomickou operaci na sběrnici třeba i u MIPSu .
Atomicita operace na sběrnici je u x86 dost jednoduchá, pokud se použije prefix LOCK (i386 má prý u XCHG LOCK implicitní), tak má sběrnici jen jeden procesor a to na celou dobu CISC operace (načtení a uložení).
. Jinak u 486 je L2 cache mimo procesor, takže tam snad není problém (nebo jí CPU před pasivní čipset ovládá? :-O).
ocfs2_fast_symlink_readpage. Patch, který to opravuje, je již k dispozici, pouze není zařazen do stable větve.
17.9.2012 15:25
Petr Tomášek | skóre: 39
| blog: Vejšplechty